User: Password:
|
|
Subscribe / Log in / New account

Unifying filesystems with union mounts

Unifying filesystems with union mounts

Posted Dec 28, 2008 22:21 UTC (Sun) by AnswerGuy (subscriber, #1256)
In reply to: Unifying filesystems with union mounts by dlang
Parent article: Unifying filesystems with union mounts

Updating the atime is in the filesystem code, below the VFS. So opening read-only would not trigger copy-up ... it simple passes through to whichever fs in the stack contained the file (inode) ... and that fs then handles it (or ignores it if noatime was set on that mount.

It's interesting to ask if it's possible to specify noatime on some layers and not on others. I see no reason it shouldn't be possible.

I would hope that the open for read-write or read-only or append would only *mark* the file for copy-up. Any subsequent write() on that file descriptor should trigger the actual copying.

The ugly bits are the -EXDEV (directory renames triggering the need for whole directory copies) and the "whiteout" entries. (I presume the later are technically vnodes ... inode-like structures existing only in the VFS and not written to any of the filesystems in the stack?)

Actually all of this raises interesting questions about different use cases for union file stacking. Should the removal of a file simply be an operation that only affects the top layer? Or should it drill down to all write-able layers in the stack? Should this "whiteout" persist through a umount/mount? How should the system handle cases where we are mounting filesystem in different stacks at different times. The simple use cases where we have one filesystem (CD-ROM, network read-only mount etc) are easy to imagine. Add a "magic" file on the top-level filesystem (like ext2/3's "bad-blocks" and "journals" --- files/inodes with no visible links, or like the .nfsXXXXXXXXX server files we see when files are removed on some NFS clients while still open on others; have this contain the whiteout data and any other semantics).

But what about when we want to use union filesystem stacks as a sort of transparent version control system? (Similar to the infamous MVFS/VOBS from Clearcase and other such systems). It gets messy to even define the desired semantics, much less implement them.


(Log in to post comments)

Unifying filesystems with union mounts

Posted Dec 29, 2008 0:46 UTC (Mon) by dlang (subscriber, #313) [Link]

if a layer is read-only then atime should not be updated on it. the definition of union mounts is that all layers except the top one will be read-only (which avoids the headache you mention of deciding which writable layer to modify)

which either means that atime is implicitly disabled by union mounts, or the upper layer needs to store it.

I don't see how directory renames are any worse than large files that get renamed or small modifications (think logfiles for example), in both cases you have a (potentially large) disk item that needs to get copied (after all a directory is just a 'file' containing pointers to file contents). or are you saying that if a directory gets renamed all the files in that directory get copied? if so then the layering also is incompatible with hard linked files.

the other option is to extend the whiteout concept to provide a 'link' type entry as well (similar to a symlink, when file X is opened on the top layer, open file Y on lower layers)

the whiteouts (and any other modifications) definantly need to persist across mounts, otherwise the result can't be considered coherent. now if you remount with a different combination of things (or modify the underlying filesystem(s) through some other mechanism) things do get interesting.

if you want version control semantics then you probably want to use FUSE, not union mounts. if you used union mounts then for each new version you would mount another 'filesystem' on top of the stack, and each version could be accessed (read only) by other processes by mounting the appropiate layers of the stack.

the issues that you would run into here would just be efficiancy in drilling down through (potentially) many layers of the stack.

but that does bring up a question, how can you query what the stack is? If many layers have been mounted over time it may not be trivial to know how to recreate the stack for the next boot if you can't query the kernel to find out.


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