Hi all,

I have designed (on paper) that my new Linux install will use several partitions to form the single root filesystem. In details it looks like this:

/dev/sda1: /boot directory
/dev/sda5: swap partition
/dev/sda6: /var/log
/dev/sda7: /var
/dev/sda8: /tmp
/dev/sda9: /usr,/bin,/sbin,/lib,/opt
/dev/sda10: /, /dev, /proc
/dev/sda11: /home, /root

However i now come to realise that it in fact may not be possible to mount the /dev/sda9 partition properly, since as far as I understood about 'mount', it will mount a single device (partition in this case) at a single filesystem point. In other words, how will I be able to keep /usr,/bin,/sbin,/lib,/opt on a same partition, and fuse them into my root tree? I really dont want to split the partition into 5, one per directory, and I dont want to have a single partition for the drive...Is my design realisable?

The reason i split the layout like this, is to optimise disk usage, since outer tracks (lower partitions) are faster.

I am considering LVM but frankly, it only creates extra block devices which have to be mounted too, so I cannot see how it would help.

Thanks...

P.S. I have crossposted this question on linuxforums.org. I dont know much about policies of crossposting, hope it is fine though.

lots of people will disagree with me but let me give you some tips.

If speed is you main concern, running default kernels and default initrd images and default modules and default services will slow you down more.

to be positive, compile your non-intrd kernel with min modules and run minimum services.

2) so if you agree, the need to have all those extra partitions become irrelevant. There are some who argue you must have this on a separate partition and I am no better. I suggest you save disk space by having the least number of partitions.

I have 3..../ and swap.....and one backup partition used for saving partimage images. It only takes me minutes to restore my entire system for an upgrade blah blah. Naturally I burn my images to dvdrw.

3) If you choose a non-journalised file system format you can speed up your boot time but I prefer XFS for that day when I have a power failure.

for your consideration

/ /dev/sda1
swap /dev/sda2
/backup /dev/sda3....all are primary partitions so a simple backup of mbr is a bonus.

I would never try to have a partitioning scheme this complicated---and I really question what the benefit would be.

This aside, I don't think it is possible to mount things the way you describe. When you mount a partition to /, then everything in / --and everything under it-- goes in that one partition. If you then mount another partition to--eg /bin, then everything in /bin goes to that partition. If you try to mount a partition to several different sub-directories, the same data will appear in all of them.

Not a guru, but I think could make the trick:

1) Put those folders in the partition you want.
2) Mount them in /mnt/sda9 (or whatever you like). You will end with /mnt/sda9/usr, /mnt/sda9/bin, etc.
3) create (sym)links from / to those folders.

Question: How much do you expect to use your swap partition? If it is not very often, maybe you would want to "reduce its priority" :-).

Anyhow, I agree that the scheme seems complicated. Be careful on the sizes you assign to each partition. Resizing later can be a mess...

Hope this helps!

And do not forget that during boot you will need content of /bin, /sbin and /lib.

How do you expect to mount /bin when executable (mount) resides in this folder?

Keep It Simple. For the average desktop, two or three partitions are enough. Either / and swap; or /, /home, and swap.

Ok, good point. How is mount available otherwise? I dont see how this is specific to /bin. How does the system bootstrap itself then, if it cannot mount partitions before mount is available, and mount is available on some partition anyways ?

In the bootloader configuration, the kernel line includes the info on which partition contains /
e.g. (for GRUB menu.lst):

..
..
kernel /boot/vmlinuz root=/dev/sda1
..
..

Later in the process, init looks at /etc/fstab for further instructions

Good point.

Btw, I remember reading on Inet of people giving advice of f.i. dedicating a separate partition for /boot also..Something like 50Mb or slightly larger. Does this mean /boot has to be the first mounted (by bootloader) partition?

Yes, i thought of symlinking. Will go against this, but thanks for advice. Really.

Ok, after the bootloader mounts the partition specified by "root" argument, and when later init looks at /etc/fstab, does this mean init still does not need the "mount" binary, or does /bin have to be available already (incidentally from the place that "root" arg specifies, looks like) ?

Some details on my setup:

1. I have a Lenovo T61 notebook waiting for this setup. Its a brick for now - i.e. clean disk

2. This will be part of automated install script, which will not be very robust since i am planning to initially only use it on the T61 machine

3. I believe significiant speed can be extracted by separating temp files, variable files, binaries, and user data onto different partition, especially for "average desktop" configuration which do some background disk stuff, like updating /var and /tmp content, since the categories of files that these partitions will host vary by lifetime, and nature of access. Besides, i would eventually like to experiment with filesystems on these different partitions, depending on the nature of files they host.

4. Swap partition is not strictly required, the noteboook has 2Gb RAM, yet i will use the swap space, just for the kicks Since the disk is 100Gb size, "reducing it's priority" (relocating it along the disk or even removing it altogether), as it occupies 1% of total disk platter capacity, will not yield any advantage, i think. So having it there, is only good if it will be used, when only 1% of total disk capacity "goes to waste".

I have to give up the layout of /dev/sda9 for reasons now obvious to me. The /usr, /bin, /sbin, /opt and /lib will go to where / is. The rest i am planning to keep.

I think you won't notice any speed increase if you try this architecture using common desktop-grade hard drives, even SATA drives. You'll be bandwidth limited in your controller, and you will be dealing with a drive command set that won't reorder requests to optimize performance.

I think you might see some benefit if you used SCSI or SAS drives, but I doubt the performance gain would justify the cost of multiple SCSI drives just for this. If you used SCSI or SAS, your overall system performance would be significantly better than a standard desktop system just because of the drives you were using; the additional delta for the partition structure you want might not be necessary or worth it.

If you did want to go with multiple SCSI drives, then using striped sets probably gives more performance advantage than breaking out partitions as you propose.
Swap is always a good thing.

or use symlinks.

Once upon a time BIOS was able to access only first 528MB of HDD, later 2GB or 8GB. Up to date mobos do not have these restrictions. As kernel is initially loaded by BIOS, it must reside in the area of the HDD visible by BIOS. If you create /boot partition as the first partition and size it 50MB you play on the safe side - its content will be visible by BIOS.

This is not a concern nowadays.

It remains a concern if you wish to use the logical volume manager (LVM). /boot won't work in an LVM environment; you have to set up a separate partition for /boot if you are going to use LVM.