User: Password:
Subscribe / Log in / New account

Another union filesystem approach

Another union filesystem approach

Posted Sep 2, 2010 12:20 UTC (Thu) by liljencrantz (guest, #28458)
Parent article: Another union filesystem approach

From my perspective, if you union mount e.g. an NFS file system and then star modifying the underlying filesystem directly, you deserve every bit of pain coming to you. It makes perfect sense to enforce anything that can be reasonably enforced, such as making sure that local file systems must be mounted read only in order to be part of a union mount, but I fail to see why one should artificially exclude e.g. NFS file systems simply because making those sanity checks aren't possible on a remote file system.

How about having an ounce of trust in the universe; competent sysadmins will get it right, and the rooting out incompetent sysadmins quickly is actually a good thing?

(Log in to post comments)

Another union filesystem approach

Posted Sep 2, 2010 13:19 UTC (Thu) by neilbrown (subscriber, #359) [Link]

It isn't about trust, it is about providing predictable behaviour in all circumstances, even weird corner cases... So maybe that is about trust - you should be able to trust the unionfs to behave predictably.

In your taxonomy of sys-admins you forgot to include the brilliant/insane ones who *know* exactly how every union-mount is being used and *knows* that a particular file that they want to upgrade isn't being used at the moment so if they replace it on the common underlay then everyone will smoothly see the new content.

To serve their interests you want unionfs to perform predictably in that situation, so that if they try something and it works, then it is likely that it will work again next time. So it is important for unionfs to understand and handle any changes in the underlying fs.

Another union filesystem approach

Posted Sep 3, 2010 0:35 UTC (Fri) by dlang (subscriber, #313) [Link]

if your underlying filesystem is a default system image and your union is then a specific system, it makes a huge amount of sense to want the ability to update the underlying filesystem and have everything using a union pick up the changes.

you may be able to unmount the overlay, but then when you re-mount it, how do you know what to do to resolve changes? In some cases you may want the new file from the underlying layer, in some cases you want the modified version from the top layer, and in many cases what you really want is the changes that were made between the old underlying file and the old upper layer to be made to the new underlying file into the new upper layer.

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