Re: [Btrfs-devel] transaction ioctls

[Bron Gondwana <brong@fastmail.fm>]

On Wed, Apr 23, 2008 at 09:23:03AM -0400, Chris Mason wrote:
> On Wednesday 23 April 2008, Evgeniy Polyakov wrote:
> > On Wed, Apr 23, 2008 at 09:07:28AM -0400, Chris Mason 
> (chris.mason@oracle.com) wrote:
> > > 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.
> >
> > Rollback happens on transaction, so first application called fsync in
> > own trasaction, which flushed data to disk, while second thread has own
> > trasaction, and that data will be removed, while data written in first
> > transaction is still on disk.
> 
> The kind of logging this requires is outside the scope of Btrfs ;)  It is 
> possible if both procs are running in different tree roots, but how about:
> 
> proc A: mkdir dir1
> proc A: create dir1/file1
> proc B: add data to dir1/file1
> proc B: fsync dir1/file1
> proc A: rollback
> 
> Filesystems can be databases, but not with the current APIs.  Userland simply 
> isn't built around these semantics today.

proc A: mkdir dir1
proc A: create dir1/file1
proc B: add data to dir1/file1
proc B: fsync dir1/file1
proc A: unlink dir1/file1
proc A: rmdir dir1

I don't see the difference.

Bron.