User: Password:
Subscribe / Log in / New account



Posted Apr 9, 2009 15:09 UTC (Thu) by ESRI (guest, #52806)
In reply to: readdir by bharata
Parent article: Unioning file systems: Implementations, part 2

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!


(Log in to post comments)


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.

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