[mdlug] More new hard drive details

Jeff Hanson jhansonxi at gmail.com
Wed Jan 14 01:15:22 EST 2009


On Wed, Jan 14, 2009 at 12:21 AM, Drew <drew4096 at gmail.com> wrote:
> The disk seems, as far as I can tell, good, so I'm going ahead. Some
> additional questions I'd like
> to field before I begin however. I've decided that I want multiple
> distributions, with the collected data
> that is not actually part of any distribution (in effect, everything
> in /usr/downloads, /usr/iso, and maybe
> /usr/vdisks) copied over to one or more partitions assigned roughly
> half of the new drive (about 160 GB),
> with the other 160 GB being split into a partition for each installed
> distro. Each distro will then have
> its own /home/drew replaced with, or contain, a symlink to the copied data.

Wouldn't virtualization be easier?

> First off, is it permissible for all these distributions to share a
> common /tmp? If so, should the /tmp
> be cleaned out on boot? On shutdown?

The only issue I can think of is that some distros start user IDs at
500 (Fedora/Mandriva?) and others at 1000 (Debian/Ubuntu).  Ownership
could be an issue but if they are not running simultaneously then /tmp
shouldn't matter.

> Next, I've noticed that newer distros are showing my IDE drives as
> sda, sdb, ... (for the hard drives)
> and sr0... for the DVD burner (and ISO images when booted in VMware).
> A little research revealed
> that it's because the IDE driver is being merged with the SATA driver
> as they want to reduce the
> amount of code they have to maintain. Also that you can still have
> your disks named hda, hdb, ...
> but it requires compiling back in the old module. Someone at MDLUG
> said there's a boot option
> that can force use of the old names.
>
> * What is that boot parameter?

According to this:
http://forums.opensuse.org/archives/sls-archives/archives-suse-linux/archives-general-questions/383771-hard-disk-being-ide-not-scsi.html#post1804846

the parameter is:
hwprobe=-modules.pata

> * Is there a reason to go along with the all scsi standard?
> * Is there a reason to try to use the old names?

I suspect most distros will use the new designations since the
decision was made at the kernel level.

> Partition size: I'd like to optimize inode and space useage. Is it
> worth while to have different partition
> sizes for different sizes of files, eg, a 100G partition for ISOs and
> other big files, a 40G partition
> for medium sized files, and a 20G partition for small files? Or at
> least different block size settings?
> (I'm going with ext3 as I'm most sure of it being readable by all distros.)

Probably not worth the trouble.  The percentage space savings would
not be significant for a variable-sized file usage like most desktop
systems (it's not like you're using FAT16 with a 32K cluster).  It's
probably not much performance benefit either for most applications.
For a single-purpose specialized function (like a news server) it may
have some benefit.

> Finally there's logical vs main partitions. As the distros themselves
> are re-installable while the data
> needs better protection I had figured on going with main partitions
> for data and logical partitions on
> an extended for swap, /tmp, and all distros. I'm pretty sure grub can
> handle it. However, the install
> programs seem to have their own ideas on how to do this; they mostly
> want to create all logical
> partitions on a single extended, with no other main partitions. Is
> there a reason for going either
> way or even doing something different?

Following the old MS-DOS partition structure you have a limit of four
primary partitions or three primary and one extended.  Only DOS and
Windows (NT-XP, and maybe Vista) require a primary partition and the
start of the partition they are located on must before the 8GB (else
they won't boot).  Linux will run from anything anywhere.

> What about LVM?

Nifty way to manage drive space but it's just container management
with some neat tricks thrown in.  Resizing an LVM partition isn't any
easier than a regular partition as you still have to extend the
filesystem within it separately.



More information about the mdlug mailing list