[Btrfs-devel] transaction ioctls

[Bron Gondwana]

On Thu, 24 Apr 2008 09:06:54 -0400, "Chris Mason" <chris.mason at oracle.com> said:
> On Wednesday 23 April 2008, Bron Gondwana wrote:
> > On Wed, Apr 23, 2008 at 09:23:03AM -0400, Chris Mason wrote:
> > > 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.
> 
> The main difference is that in the unlink case, the unlink goes through a 
> series of code in the VFS to make sure that open file handles stay viable
> and that all of the other posix rules are followed.  In the rollback case,
> the filesystem has to do all of that on its own.
> 
> Here's another:
> 
> proc A: mkdir dir1
> proc B: open dir1/file1 O_CREATE
> proc A: rollback
> proc B: close
>
> [... I've trimmed the following a bit, it's only partially quoted...]
> 
> Doing the same thing with rmdir would fail because the directory wasn't
> empty.  In order to provide the rollback, the FS would have to wander
> through all of  the dentries and do something sane with them....
>
> The main point is this kind of thing is littered with corner cases. 
> You'd  have to find each file or directory affected by the rollback
> and make sure appropriate actions are taken for each one, and get
> it done in a VFS friendly deadlock free way.

Yeah, that's a good point.  I suspect my first pass idea for this would
look remarkably like a soft-mounted NFS drive that had been disconnected.
Ooops, your little bit of filesystem went away - EIO, byebye.

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm