On Sat, 26 Sep 2009, Daniel J Blueman wrote: > On Fri, Sep 25, 2009 at 10:10 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > So, the btrfs user transaction ioctls work like so > > > > ioctl(fd, BTRFS_IOC_TRANS_START); > > /* do many operations: write(), setxattr(), rmdir(), whatever. */ > > ioctl(fd, BTRFS_IOC_TRANS_END); /* or close(fd); */ > ... > > The second problem is that the application may die between START and > > END. The current ioctls are "safe" in that the transaction handle is > > closed when the struct file is released, so the fs won't get wedged if > > you say segfault. On the other hand, they're "unsafe" in that a process > > that is killed or segfaults will result in an imcomplete transaction > > making it to disk, which leaves the file system in an inconsistent state > > (from the point of view of the application). > > With COW, where a transaction is incomplete due to application exit > without closing the transaction, is there a way to drop the > reference/'deallocate' the new tree nodes, thus moving back to the > prior state? Presumably the new tree nodes would get linked in when > the transaction is closed. Not quite. These are not full ACID transactions.. they're only giving you atomicity and durability. Adding the rollback would mean a huge addition of complexity, both in rolling back the btrfs and VFS inode/dentry/page cache states. The current ioctls are quite simple because they hook into the existing btrfs transaction infrastructure that lets multiple btree updates (and, optionally, file data) commit to disk together. For many applications, atomicity is enough, because they aren't sharing the files/directories they're working on with other applications. They know whether an update should succeed. We just need to ensure common failures like ENOSPC and crashes do not violate that atomicity. sage
