LWN: Comments on "Unionfs"

Unionfs

TomasM — Sun, 27 Jan 2008 15:00:39 +0000

Well, aufs is a great replacement for unionfs. That particular code should be in kernel IMHO,
as it's working much better. It is documented in aufs.5 man page: http://aufs.sf.net/aufs.html

Knoppix switched to AUFS already, all linux-live based distributions including Slax are
switching to AUFS as well. Junjiro Okajima (AUFS author) sadly doesn't wish to submit the code
to kernel yet, while unionfs developers try very hard to get it inthere, have no idea why is
that so important for them. The inclusion won't make unionfs code better.

If you review the unionfs versus aufs development process, AUFS adds cool features (like
balancing of writable branches), while unionfs fixes locking, mmap code, NULL pointer
dereferences, and so on. ..

Unionfs

JohnNilsson — Mon, 15 Jan 2007 14:02:18 +0000

Is this an application that would benefit from this
Zipper-based file server/OS thing I saw the other day?

http://okmij.org/ftp/Computation/Continuations.html#zippe...

From my limited understanding it's a copy on write based way to make an immutable data structure mutable which kind of sounds similar to some of the goals of unionsf.

Unionfs

PlaguedByPenguins — Sat, 13 Jan 2007 15:14:25 +0000

for clusters, the 'no writes to underlying layers' thing is a killer - it means you can't upgrade the read-only part of the OS. it would be great if unionfs would recognise when VFS caches were trashed.
in the mean time, I've found oneSIS is a simple and effective way to diskless boot clusters.

cheers,
robin

Unionfs

aakef — Sat, 13 Jan 2007 11:29:20 +0000

Hi dambacher,

we are just trying to use funionfs (also fuse based) as diskless setup. In principle it already works, but I found one critical bug, see here

http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2007-Janua...

I looked into the sources of unionfs-fuse and I think it will have the very same access() problem.

All I need is a good idea how to fix it. Since everything is done in userspace, the source code is rather simple.

If you need some help to setup your diskless setup, just contact me.

Cheers,
Bernd

Unionfs

raven667 — Sat, 13 Jan 2007 04:52:17 +0000

You cannot oops the kernel by writing to /dev/hda1 while an ext3 filesystem on /dev/ hda1 is mounted. You can trash unlimited amounts of data, but as the filesystem is external to the kernel, the kernel is robust to whatever bits it might read from it at any time.

That seems like how it should be but I doubt that this is true. In fact I believe one of the major fixes in 2.6.19.2 is CVE-2006-5823 a problem where a corrupte cramfs could OOPS the kernel. This same kind of think can, has and will continue to happen in the filesystem, USB, network, Firewire, block device and other subsystems where bogus data from a piece of hardware isn't sufficiently checked before being used and causes an OOPS (with potential security implications.

Unionfs

giraffedata — Sat, 13 Jan 2007 00:33:44 +0000

later messages in the thread indicate that the warning is (somewhat) intentionally overstating the risk of an oops

Do you mean the warning is a lie and it is not in fact possible by design to oops the kernel by modifying an underlying filesystem?

Because that's the only way it's sensible. You cannot oops the kernel by writing to /dev/hda1 while an ext3 filesystem on /dev/hda1 is mounted. You can trash unlimited amounts of data, but as the filesystem is external to the kernel, the kernel is robust to whatever bits it might read from it at any time.

Unionfs

dambacher — Thu, 11 Jan 2007 22:14:16 +0000

some days ago I searched for unionfs and lookalikes to set up a diskless boot and wondered.
there is more than just unionfs:
unionfs-FUSE is based on unionfs with some interesting features
aufs is a new implementation of uionfs. knoppix just switched from unionfs to this one.

none is in kernel but FUSE annd unionfs-FUSE runs in userspace.
none has good documentation .-(
special tricks like root mounting are not documented.

You could also update the DVD

mcmechanjw — Thu, 11 Jan 2007 16:19:47 +0000

While it is true that unionfs is a nice way to provide updates to a DVD growisofs provides for adding files to a already written DVD+/-R/RW/RAM directly via the -M option until it is full or the disk is closed
As a example a script I use looks like this - most of which is concerned with updating the md5sum file, and then checking the md5sum of the files on the dvd.

mount /mnt/dvd
cat /mnt/dvd/md5sum >>md5sum
find $FILES -type f -print0 | xargs -0 md5sum >>md5sum
umount /mnt/dvd
ulimit -l unlimited
growisofs -M /dev/dvd -r $FILES md5sum
mount /mnt/dvd
(cd /mnt/dvd;md5sum -c md5sum)

Unionfs

nix — Thu, 11 Jan 2007 11:33:41 +0000

unionfs also stops unioning at mount points, which is really annoying and makes it unusable for a lot of purposes. e.g. a lot of the path-translation stuff in fakeroot could be avoided (and robustness improved) if you could union-mount the fakeroot directory over / before running the fakerooted command, so the changes that `make install' or whatever did landed in the fakerooted directory, but it normally saw the original /. But this doesn't work because of the mount-point-traversal problem.

(Oh, and also the corruption thing as well, of course: it's kind of annoying to avoid writing to /-and-all-subdirectories while fakeroot is running :) ).

Unionfs

dlang — Thu, 11 Jan 2007 09:50:20 +0000

writing to the underlying filesystem is conceptually the same as writing to /dev/hda1 while you have it mounted.

in both cases the filesystem on top doesn't know about the changes below it and can be (fatally) surprised when it finds them.

later messages in the thread indicate that the warning is (somewhat) intentially overstateing the risk of an oops (rather then going into many pages of quickly obsolete details of what will fail)

I suspect that you get away with it by the fact that you are doing read-only on the result.

Unionfs

smurf — Thu, 11 Jan 2007 09:45:32 +0000

Ubuntu has been shipping their kernels with unionfs (and squashfs) for a year now, in order to support live CDs properly.

In that case, modifying unionfs parts from behind the scenes is Not A Problem because the r/w branch is hidden by the clever way the initramfs sets up the file system structure -- the unionfs is mounted at /root, and then /root is move-mounted on top of /.

But I can certainly attest to its fragility in the general case -- trying to restore an unionfs filesystem by simply pulling the r/w part from a disk dump does cause a crash pretty much immediately afterwards: unionfs sees some cached directory entries which do not have its data structure attached, and BUG()s out.

Unionfs

k8to — Thu, 11 Jan 2007 08:07:33 +0000

Huh, I modify the contents of a branch out from under a union mount just about every day. In fact, that's the only way I ever modify it.

I have yet to see a single oops or data loss problem.

Surely there must be more to triggering this problem.