On Thu, 24 Apr 2008 09:06:54 -0400, "Chris Mason" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
