[lkml]   [1999]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: FS Unions
    <sound of lurker decloaking)

    how about ._part1, ._part2 etc...

    if you create a file it goes in the primary mount (which does not have a
    fugly .dir) but if you want to put it on another partition that has been
    "unionized" then

    cp foo /bar/thisdirisunionized/._part1

    and it will be copied there

    cd /var/this...
    ls ._part1
    would give a list of all files that are from that partion, (ie a subset of
    ls .)

    mv ./baz ./._part1/baz would move the file from whatever unioned partition
    to that particular unioned partition, it would still appear in the main

    the whole ._part? thing is a kludge, but it does seem to work for every
    possible complication/permutation...

    now if only I knew how to code this into being ;-)


    Today: Lou Grinzo speaks on FS Unions

    LG: The recent talk about fs unions (mounting more than one set of
    LG: files at the same mount point and merging the dir. contents) is
    LG: certainly intriguing.
    LG: Would the feature be limited to two mounts per point? Would it
    LG: only allow mounts from the same drive, same partition, same
    LG: locale (meaning local vs. networked), or from any valid drives?
    LG: How would file creations be handled (assuming all unioned file
    LG: space is R/W)? I imagine there would have to be some very
    LG: specific rules governing this, e.g. the first mount is considered the
    LG: "primary" one and gets all file creations, barring any override from
    LG: the user/programmer. (And no, I haven't considered exactly how
    LG: such an override should be done.) Or does the location with the
    LG: most free space get the new file? Or would file creations be
    LG: prevented entirely? (That would certainly clean things up for the
    LG: implementation, but it could create severe usability problems,
    LG: so is probably not feasible.)
    LG: To create a fully-realized implementation, would there have
    LG: to be modifications to commands or facilities to take into account
    LG: or exploit the fs unions? If so, this might be a way for some others
    LG: to contribute to the effort and produce a better integration of the
    LG: feature into the Linux environment.

    Rahul Sinha ICQ# 9738191 AOL IM: vox deus
    Freshman Vice President, UMd Debate Team
    Computer Science / Government Treasurer, UM Linux Users' Group
    University Of Maryland College Park Enlightenment Documentation Project

    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.023 / U:11.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site