Re: [Btrfs-devel] transaction ioctls

[Chris Mason <chris.mason@oracle.com>]

On Wednesday 23 April 2008, Evgeniy Polyakov wrote:
> Hi Chris.
>
> On Wed, Apr 23, 2008 at 08:50:54AM -0400, Chris Mason 
(chris.mason@oracle.com) wrote:
> > Transaction rollback from a filesystem point of view is a reboot.  Real
> > database style transactions with rollback and isolation from other procs
> > etc etc are outside the scope of Btrfs.
>
> Why rollback is a reboot? With copy-on-write it could be possible to
> just commit tree state, which was before transaction start, as a current
> one and thus rollback all changes. Having that possibility from
> userspace could be a great benefit, since in case of application error
> it is relly simple to undo all changes.

Oh, from a filesystem point of view it is very simple to undo changes, 
especially with COW.  We've got snapshots and we can pull old copies from an 
old snapshot etc etc.

But, userland expects things not to be undone.  Picture two procs operating in 
a directory.  One proc calls fsync and gets assurance from the FS that things 
are on disk.  The other proc calls rollback and undoes the fsync.  The posix 
API isn't built around this.

There are definitely cases where the admin will want to be able to run a 
command to shift the FS state back to some time in the past.  But, it needs 
to be an admin level tool where the complex interactions between procs are 
well understood (by the admin).

-chris