[Btrfs-users] Thoughts about filesystem undo

[Chris Mason]

On Wed, 2007-09-26 at 22:55 +0100, Phil Endecott wrote:
> Hi Chris, thanks for replying.
> 
> Chris Mason wrote:
> > On Tue, 2007-09-25 at 23:45 +0100, Phil Endecott wrote:
> >> Dear Btrfs people,
> >> 
> >> I saw Chris' Btrfs talk at LinuxConf.EU a few weeks ago and have since 
> >> been thinking about how I would like to use this great code once you 
> >> have done all the hard work :-)
> >> 
> >> Fine-grain filesystem undo, thanks to cheap snapshots, is what I'm 
> >> thinking about.  The more I consider it the more useful I believe it 
> >> will be
> [snip]
> >> So I was wondering if you have thought about how this could be made to 
> >> work, from the user's (or application developer's) viewpoint rather 
> >> than in terms of the filesystem implementation.  Certainly, more than 
> >> just "snapshot create" and "snapshot delete" commands are needed.
> >> 
> >> One idea is to automatically take a snapshot when each processes 
> >> starts, and to keep it until its parent process terminates.  This means 
> >> that from the command line I can rollback to between any commands in 
> >> that shell's history.  Perhaps applications that suffer an error could 
> >> choose to revert all their changes on termination.
> >
> > There are a lot of different factors in play here.  First, once a new
> > snapshot is created, additional COW runs are required for any tree
> > metadata related to the snapshot.
> 
> Sure.  Like many things, the user will want to weigh the benefits 
> against the costs.  But I think that the costs are now tractable, so 
> it's worth considering what the benefits could be.
> 
> 
> > Picture a directory where process A and process B are both writing.
> 
> Hmmm, the complex case.  I'm not even sure what should happen in the 
> easy case yet.  But anyway -
> 
> > Process A decides it is time to rollback some changes, but what do we do
> > with process B?
> 
> Was it actually accessing the same files, or just files in the same 
> directory?  Were both processes writing, or just one of them?  In a lot 
> of cases, if two processes are writing to the same file, the user has 
> made a mistake and something bad is going to happen; so any behaviour 
> would be better than the current situation.
>
> But let's back off to the simpler case without conflicts.

The problem in this case is, how does the kernel decide when there are
conflicts?  This kind of tracking of visible changes gets very complex
in a hurry, especially when you then try to apply good old fashioned
posix filesystem semantics on top.

It is surely an interesting project, but well outside the scope of what
btrfs will be able to do this year ;)

-chris