> The recent talk about fs unions (mounting more than one set of
> files at the same mount point and merging the dir. contents) is
> certainly intriguing.
>
> Would the feature be limited to two mounts per point? Would it
> only allow mounts from the same drive, same partition, same
> locale (meaning local vs. networked), or from any valid drives?
Huh? Please, take any *BSD and look how it is done there. It works so -
you have an ability to make transparent mount:
* when you are looking up a directory entry for 'foo':
* it is looked up in the overlapping filesystem first. If
it is found - fine, we got it.
* otherwise, look for whiteout entry with that name (also
in overlapping fs). If found - return -ENOENT (file
doesn't exist).
* otherwise (neither normal nor whiteout entries are there)
look into the underlying layer.
* Not found there - return -ENOENT.
* Found and is *not* a directory - got it.
* Found and is a directory - create an empty directory
with the same name in overlapping fs.
* to create a directory entry:
* look for whiteout entry with that name (in overlapping
fs). If not found - just go ahead and act as for normal
filesystem. If we are creating a directory mark it
non-transparent (see below).
* if found and we are creating *not* a directory - remove
whiteout and act as for normal fs.
* if found and we are creating a directory - remove
whiteout, create a directory *and* mark it as
non-transparent. That is, in that directory and all its
subdirectories we are acting as for the usual mount - no
lookups into the underlying level.
* to remove a directory entry:
* if there is an entry with that name in overlapping fs
and nothing under it - simply remove.
* if there are entries both in overlapping and underlying
layers - replace the overlapping one with whiteout.
* if there is no entry in overlapping layer - create a
whiteout.
All modifications go into the overlapping fs. All you need from it is a
way to represent whiteouts (normally done as entries with reserved
inumber value).
Essentailly it's a transparency - you are placing it over the
part of existing tree and all *namespace* changes go on it. You can put an
additional layers atop of it, indeed. Once you got a file - you got it.
I.e. if you reached a file with no overlapping counterpart and opened it
for write - you've opened it for write.
> How would file creations be handled (assuming all unioned file
> space is R/W)? I imagine there would have to be some very
> specific rules governing this, e.g. the first mount is considered the
> "primary" one and gets all file creations, barring any override from
> the user/programmer. (And no, I haven't considered exactly how
> such an override should be done.) Or does the location with the
See above.
> most free space get the new file? Or would file creations be
> prevented entirely? (That would certainly clean things up for the
> implementation, but it could create severe usability problems,
> so is probably not feasible.)
Damnit, just do a search for unionfs - the thing is at least 4
years old (in its current form, ancestors are much older). It is described
in many places and there is free implementation (4.4BSD and derivatives).
> To create a fully-realized implementation, would there have
> to be modifications to commands or facilities to take into account
> or exploit the fs unions? If so, this might be a way for some others
mount(8), umount(8) and fsck(8). Mount should be taught to deal
with the new flag, fsck should be taught to that whiteouts are valid
entries. Other than that... Some utility to find and remove whiteouts.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/