User: Password:
Subscribe / Log in / New account



Posted Apr 9, 2009 8:56 UTC (Thu) by bharata (subscriber, #7885)
Parent article: Unioning file systems: Implementations, part 2

If you say no to NFS export, do you see any issues with implementing readdir in glibc ?

(Log in to post comments)


Posted Apr 9, 2009 15:09 UTC (Thu) by ESRI (guest, #52806) [Link]

NFS exporting union mounts is one of my personal top use cases unfortunately. :-) We use the FUSE based unionfs[1] for doing distro mirroring based on ISO files.

We loopback mount all the ISO's, then union these filesystems together to "recreate" the appearance of one tree with everything in it, then are able to export all of this via NFS to clients. We now have the raw .iso files available, each disk individually as well as a merged tree.

This probably isn't the most typical use case for unioning :-) It works, but is rather slow as you might imagine... and our /etc/exports file is very ugly indeed!



Posted Apr 9, 2009 16:09 UTC (Thu) by kfiles (subscriber, #11628) [Link]

It would seem that a possible extension of the proposed rule, "no NFS export of unionfs," could be, "no NFS export of unionfs unless all members of the union are RO." If no writes are being performed, the inodes are certainly stable.

That would solve your use case, where you really just want a union mount to implement logical volumes, not true FS overlay with transparent write-through.



Posted Apr 9, 2009 19:26 UTC (Thu) by jblunck (subscriber, #27345) [Link]

Having 'stable inode numbers' is a little bit confusing here. In general it is true what you are saying but with NFS we also have the problem that we would need unique inode numbers to export them. Since the VFS based union mount implementation doesn't come with their own inodes but directly hands out the underlying filesystems objects this requirement isn't given.


Posted Apr 9, 2009 19:20 UTC (Thu) by jblunck (subscriber, #27345) [Link]

Distros usually create full trees in a different way than the DVD flavors (at least SUSE is doing that). Unioning multiple DVDs together to one tree doesn't work reliable that way. You usually don't have the package metadata for that unified repository. Therefore you would call createrepodata anyway. Therefore it isn't necessary to use union mounts for that in the first place.


Posted Apr 9, 2009 19:53 UTC (Thu) by ESRI (guest, #52806) [Link]

In our case we were unioning the various CD's together (not DVD ISO's). Primarily with RH/Fedora/CentOS (users can point their installers to the union'd tree for installs vis HTTP, NFS, etc). I also do this with the SLES10 CD ISO's, but it's used much less frequently here although I believe it's been working as well but could be wrong.


Posted Apr 9, 2009 19:24 UTC (Thu) by vaurora (guest, #38407) [Link]

There are some things can only be implemented with a unioning file system, like a read-write layer on top of a shared read-only layer. But there are other things that are more efficiently or easily implemented via the usual mechanisms - normal mount points, bind mounts, and plain ol' cp -r. It is tempting to view unioning file systems as the Swiss army knife of system management, but that's the kind of feature creep that results in an unmaintainable buggy system.

Remember the source control use case for original Plan 9 and BSD union mounts - you don't actually want a union mount, you want a full-fledged source control system.


Posted Apr 9, 2009 23:16 UTC (Thu) by vaurora (guest, #38407) [Link]

I thought your summary was pretty good:

Clearly, this works since it is what BSD has been doing for years. But I don't like the idea of caching the entire directory very much. Dealing with directories with lots of entries is often not ideal, and this will add another constraint on the size of directories. For small directories, this works fine. For large directories, suddenly the size of directories is related to the amount of memory you have available. Imagine not being able to do an ls because you don't have enough memory to process the whiteouts - which you could fix if you could delete some files - but you don't know what the files are named because readdir() fails...

I'm sure you've thought about this more than I have, though. Any thoughts?


Posted Apr 11, 2009 5:14 UTC (Sat) by bharata (subscriber, #7885) [Link]

As you note, memory is a problem with glibc implementation with large directories. Your proposed scheme for readdir looks good, except that I find it a bit restrictive to tie a top layer to a bottom layer. I guess with you scheme, once you do a union mount, you can't re-union the top layer on top of any other layer.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds