[lkml]   [1999]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: FS Unions

    On Mon, 14 Jun 1999, Lou Grinzo wrote:

    > 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
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.022 / U:8.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site