UnionFS to add disk space to mounted directories

April 15, 2007 1:30 PM

I have a new hard drive that I have added into my system. I've partitioned it three ways. The first partition is what I would like to add onto /opt, the second is some additional swap (added with no problem), and the third is the one that I'd like to add onto /home. How do I make this work with UnionFS?

I still have my old drive set up, and I do not wish to lose this. My current partition set up is as follows:
/dev/hda3 on / type reiserfs (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
udev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw,nosuid,noexec)
/dev/hda5 on /var type reiserfs (rw,noatime)
/dev/hda6 on /home type reiserfs (rw,noatime)
none on /dev/shm type tmpfs (rw)
none on /proc/bus/usb type usbfs (rw)
And I just added on the following two lines with some manual mount commands, that I've also reproduced in my /etc/fstab:
/dev/sda1 on /.union/opt1 type xfs (rw)
/dev/sda3 on /.union/home1 type xfs (rw)

I tried the following, and got the error message as included:
# unionctl /home --add /.union/home1/
/home is not a valid union.

What am I missing? Most references I see use UnionFS for unioning together a RAMdisk and a ROM of some sort (CD/DVD/chip), but all mention it's possible to do this with all members being read-write. Will I have to create temporary mountpoints for all my drives (i.e. /.union/homeoriginal and so on?) and how would that effect my /opt which belongs to /?

posted by Xoder to Computers & Internet (8 answers total)

Best answer: Reading the man pages real quick, I think you need to do something like this:

mount /dev/hda6 /.union/home1
mount /dev/sda3 /.union/home2

mount -t unionfs -o dirs=/.union/home1=rw:/.union/home2=rw unionfs /home

unionctl only appears to be good for modifying /home after you've mounted it as above.
posted by sbutler at 2:00 PM on April 15, 2007

Response by poster: That's what I feared. But what do I do about the space I want to add to /opt if it's currently under my / filesystem? Should I just stop messing with it, move all my current /opt there and just remount it there, I guess?
posted by Xoder at 2:49 PM on April 15, 2007

You tried it? It works? I don't have any experience with unionfs, but I'd suggest you just move /opt to /.union/opt1. From there it's the same as home.
posted by sbutler at 2:58 PM on April 15, 2007

Best answer: Thanks for the help. Everything works swimmingly well now! Here's my current fstab:
# /etc/fstab: static file system information.
# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/fstab,v 1.14 2003/10/13 20:03:38 azarah Exp $
#
# noatime turns off atimes for increased performance (atimes normally aren't
# needed; notail increases performance of ReiserFS (at the expense of storage
# efficiency). It's safe to drop the noatime options if you want and to
# switch between notail and tail freely.

#

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
/dev/hda1 /boot ext2 noauto,noatime 1 1
/dev/hda3 / reiserfs noatime 0 0
/dev/hda2 none swap sw 0 0
/dev/hda5 /var reiserfs noatime 0 0
/dev/hda6 /.union/home0 reiserfs noatime 0 0
/dev/dvd /mnt/cdrom iso9660 noauto,ro,user 0 0
#/dev/fd0 /mnt/floppy auto noauto 0 0
/dev/sdb1 /mnt/usb vfat noauto,user 0 0
/dev/sdb2 /mnt/ipod vfat noauto,user 0 0
/dev/sda1 /opt xfs defaults 0 0
/dev/sda2 none swap sw 0 0
/dev/sda3 /.union/home1 xfs defaults 0 0
unionfs /home unionfs dirs=/.union/home0=rw:/.union/home1=rw 0 0

# NOTE: The next line is critical for boot!
none /proc proc defaults 0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
# use almost no memory if not populated with files)
# Adding the following line to /etc/fstab should take care of this:

none /dev/shm tmpfs defaults 0 0

none /proc/bus/usb usbfs defaults 0 0

The key lines are bold. A bootable CD took the edge off while I moved my /opt. Thanks for the clear head looking at the "why don't you just move the whole directory?" solution.
posted by Xoder at 3:59 PM on April 15, 2007

n/p. This was easy to figure out compared to the EVMS system I'm running at home :).
posted by sbutler at 4:08 PM on April 15, 2007

Am I right in believing that even if both branches of the union are R/W, only the top layer will ever actually be written to? In other words, if you're going to do this, isn't it best to let your existing /home and /opt get very nearly full before cranking up unionfs?

Also, to make best use of available space, you probably want to avoid modifying any large but existing files on /home or /opt, since unionfs's copy-on-write semantics mean that the original versions won't ever go away, just become inaccessible; they'll still be consuming disk space.

If your aim is to build an endlessly-upgradeable storage facility, you might want to look into using LVM instead.
posted by flabdablet at 12:21 AM on April 16, 2007

Response by poster: flabdablet, I thought the copy-on-write was the behavior when one branch was read-only? My /opt is now its own partition, and while the /home union seems to be working correctly, I'm not entirely certain as this morning I woke to a "disk full" error from a BitTorrent download. Restarting BT seemed to cause a lot of disk access. I'm guessing it's copying over the old file to the new drive, and will then resume my transfer, but what happens to the old file piece is a good question...
posted by Xoder at 6:44 AM on April 16, 2007

I'm pretty sure the whole copy-on-write thing is integral to the way union mounts work.

I don't think they figure out all by themselves which actual device contains the unknown amount of disk space you're about to consume with your newly created file.

I could well be wrong.

However, when 500GB drives drop to the $/MB price point currently occupied by 320GB drives, and my Ubuntu server box gets its next drive (it currently has one 250GB, one 320GB), I'll personally be going the LVM route. I should probably have done it before expanding my present capacity beyond what would fit on the smaller of my existing drives; I see much backup-shuffling in my near future, but hopefully once LVM is in and running I won't have to do that again :-)
posted by flabdablet at 8:23 AM on April 16, 2007