lkml.org 
[lkml]   [2002]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: filesystem transactions (was Re: linux-2.5.4-pre1 - bitkeeper testing)
Tom Lord wrote:

>On this thread, you (Hans) seem to be referring to some plan you have
>for putting versioning functionality in the filesystem and that you
>think this somehow gives you (at least significant parts of) revision
>control nearly for free. It isn't clear from just the messages in
>this thread exactly what plan for versioning you have in mind.
>
>It's an interesting topic, though. Is there a document available that
>actually specifies what you have in mind?
>
>Leaving aside the question of remote access, a useful filesystem
>primitive for revision control would be the ability to quickly create
>copy-on-write clones of trees (much like the Subversion model, but as
>a true file system, and without the need to store modified files as
>diffs).
>
>One could do that reasonably well entirely in user space in a portable
>way by using `link(2)' to create the clones and imposing a layer
>between libc `open(2)' and the kernel call, though every program on
>the system would have to be linked with that special version of
>`open'. An in-kernel implementation would have the slight advantages
>that it wouldn't require a special version of `open' and could,
>perhaps, at the cost of some complexity, create clone trees more
>cheaply when the expected case is that large subtrees will never be
>modified in either the original or the copy.
>
>Another user-space approach, less successful at creating clones
>quickly but portable, venerable, and not requiring a special version
>of `open' is to make the clones read-only and create them with a
>program that copies modified files, but links unmodified files to
>their identical ancestors in earlier clones.
>
>One can also do cheap tree cloning reasonably well using directory
>stacks and an automounter: a solution based on kernel primitives with
>no particular impact on the representation of the filesystem on disk,
>implementable at a higher level and compatible with all underlying
>disk representations.
>
>Of course, automated file backups of the sort described in this thread
>for VMS, are not particularly helpful for revision control.
>
>Finally, if clones really are cheap to create, that gives us an 80%
>solution for generalized filesystem transactions. Adding the ability
>to do page-based copy-on-write for individual files gives us 90%. Put
>cheap and well designed user-defined name-spaces in combination
>with those features, and we can watch Oracle fall down and go boom.
>
>None of these approaches I've mentioned require anything special from
>the filesystem representation on disk. There would be a severe
>portability problem and performance limitations to any approach that
>does rely on a particular filesystem representation.
>
>So, what exactly is your plan?
>
>-t
>
>
Since reiser4 is in feature freeze, let's defer this thread until
October, ok? It will be a long one I think.....

Hans


-
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: 2005-03-22 13:25    [W:0.140 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site