lkml.org 
[lkml]   [2007]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Versioning file system
    Chris Snook wrote:
    > The underlying internal implementation of something like this wouldn't
    > be all that hard on many filesystems, but it's the interface that's the
    > problem. The ':' character is a perfectly legal filename character, so
    > doing it that way would break things.

    But to work without breaking userspace it would need to be a character
    that would pass through any path checking routines, ie be a legal path
    character.

    > I think NetApp more or less got the interface right by putting a
    > .snapshot directory in each directory, with time-versioned
    > subdirectories each containing snapshots of that directory's contents
    > at those points in time. It keeps the backups under the same
    > hierarchy as the original files, to avoid permissions headaches,
    > it's accessible over NFS without modifying the client at all,
    > and it's hidden just enough to make it hard for users to do something
    > stupid.

    My personal implementation idea was to store lots of files for the form
    file:revision_number (I'll keep using that until somebody sugests
    something better) on the file system itself, with a hard link form the
    latest version to file (this is probably not a major imporvement and
    having the hard link coudl make it hard to implement deltas). This could
    mean no changes to the file system itself (except maybe a flag to say
    its versioned). The kernel would then do the translation to find the
    correct file, and would only show the latest version to userapps not
    requesting a specific version.

    > If you want to do something like this (and it's generally not a bad
    > idea), make sure you do it in a way that's not going to change the
    > behavior seen by existing applications, and that is accessible to
    > unmodified remote clients. Hidden .snapshot directories are one way, a
    > parallel /backup filesystem could be another, whatever. If you break
    > existing apps, I won't touch it with a ten foot pole.

    The whole interface would be designed to give existing behavior as
    default for two reasons: users are used to opening a file and getting
    the latest version and not to break userspace. I personally wouldn't
    touch this either if it broke userspace. The only userspace change would
    be the addition of tools to manage the revisions etc. Userspace could
    later upgrade to take advantage of the new functionality but I cannot
    see the worth in breaking it.

    For an example of a working implementation see:
    http://www.o3one.org/filesystem.html

    Jack
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-16 10:29    [W:8.541 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site