sean finney on 27 Oct 2011 03:53:10 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Multiple Mounts on 1 Partition?


On Thu, Oct 27, 2011 at 05:26:01AM -0400, Casey Bralla wrote:
> Following up on my posts about SSD's and HDD's, I will want to mount multiple 
> directories on an SSD, while also mounting multiple on directories on an HDD.  
> To the best of my knowledge, this cannot be done.  (You have to mount each 
> directory to a unique partition.)

I think there's some slight vocabulary fail here (see further below)...

> Since the SSD is so small, I don't want to squeeze the files into several 
> small partitions, any one of which may run out of room while the other 
> partitions still have plenty of space.

the counter-argument is that you also don't want runaway file i/o in
one directory to fill up the (only) filesystem.   It's a bit of a

generally speaking, I think LVM is a decent way around this problem.
you start off with a moderately conservative allocation to each
filesystem, and leave the rest of the extents as "unallocated".  when a
filesystem gets close to full, you just add them to the corresponding
logical volume, and grow the filesystem (which these days is usually
something you can do online, without remounting).

> So, what I _WANT_ to do is:
> mount /boot on /dev/SSD
> mount /usr/bin on /dev/SSD  (same partition as /boot)
> mount /home on /dev/HDD
> mount /bin on /dev/HDD (same partition as /home)
> etc,etc

I think this is a case of premature optimization.  it's a good
premise, splitting the different "classes" of disk out, but
specifically having /bin or /usr/bin on a seperate filesystem won't give
you any kind of performance benefit, for a number of different reasons.

 * linux fscache means most accesses of the file will be from memory,
   not from disk
 * usually the actual ELF binary is only a small fraction of the data/io
   needed to run the program (shared libraries in /usr/lib, i18n files in
   /usr/share, etc)
 * over-partitioning (on a single block device anyway) means extra disk
   seeks between partitions that are likely further apart than the data
   would otherwise be.

So I don't think you really want to do that.  Furthermore, /bin as a
seperate filesystem is entirely impossible, as it must be on / (/bin
contains binaries that must be available when only / is mounted).
You might argue that having a seperate /usr vs / would be a good boundary
line, but these days thanks to the misguided efforts of some distros
(*cough* fedora *cough*), it's becoming more irrelevant and possibly
even problematic to try.

Otherwise, some comments:

 * Having /home on a seperate filesystem is definitely smart, for several

 * Having a seperate /boot is normally not necessary, unless you're doing
   something "complicated" (i.e. lvm + md + grub 1.x, / via SAN, etc).  But
   if you *do* choose to do so, think long and hard about how big you'll
   need it, then double it, and then double that.  I have had more than
   one laptop run into problems down the line with /boot filling up.

 * The most active location for I/O (apart from possibly /home, anyway)
   is /var , (logs, apt, dpkg, sockets, etc), so you might want to have
   a /var filesystem demoted to your HDD if you want to preserve I/O on
   the SSD.

Given what you've described above, that you want the SSD as a first-class
disk but want to have the data-intensive (in storage size and write-heavy
I/O) areas on the HDD, I would suggest something like the following:

/dev/sda (the SSD):
	sda1 -> /

/dev/sdb (the HDD):
	sdb1 -> /var
	sdb2 -> /home
	sdb3 -> swap (if needed)
	sdb4 -> /tmp + tmpfs if low-RAM

Although actually, I'd also want to throw LVM in there, largely
because then you don't have to stress about getting the partitions
right on the first time (i.e. easy to grow later).

/dev/sda (the SSD):
	sda1 -> /

/dev/sdb (the HDD):
	sdb1 -> swap (if needed)
	sdb2 -> lvm pv in volume group named vg_hdd

	lv_var -> /var
	lv_home -> /home
	lv_swap -> swap (as an alternative to sdb1, if you're not as
	                 RAM starved)
	lv_tmp -> /tmp + tmpfs, if low-RAM

> Anybody know if there is a way to mount multiple directories on the same 
> partition while still preserving the normal Linux File Standard?

you mount a partion on a directory, not the other way around.  or more specifically,
you mount a *filesystem* on a directory, where the filesystem may be on
a partition, or may be on some other block device (whole disk, loop,
md, lvm, dm, etc).  But I guess that's kinda distracting from what you're
asking, and I hope the above helps with that anyway :)

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --