On Wed, Nov 11, 2009 at 06:41:06PM +0300, Andrey Kuzmin wrote: > >> I hadn't looked into this before, but I think the snapshots could be used > >> to achieve both atomicity and rollback. If userspace uses an rw mutex to > >> quiesce writes, it can make sure all transactions complete before creating > >> a snapshot (commit). The problem with this currently is the create > >> snapshot ioctl is relatively slow... it calls commit_transaction, which > >> blocks until everything reaches disk. I think to perform well this > >> approach would need a hook to start a commit and then return as soon as it > >> can guarantee than any subsequent operation's start_transaction can't join > >> in that commit. > >> > >> This may be a better way to go about this, though. Does that sound > >> reasonable, Chris? > > > > Yes, we could do this, but I don't think it will perform very well > > compared to your multi-operation ioctl. It really does depend on how > > often you need to do atomic ops (my guess is very). > > > > Honestly you'll get better performance with a simple write-ahead log > > from userland: > > Write-ahead logging is necessary anyway if the aim is to provide > transactional semantics to an application.
Sage's big fat ioctl does provide the subset of transactional semantics that ceph (and many other apps) require. In this case, they just want to know that a given set of operations will happen together. > But, at the same time, w/o > snapshot there is no synchronization between the log and file-system > state. Synchronizing the log and the filesystem state happens when the application starts up after the crash (either app crash or system crash). The application would be in charge of applying the log to its own files to get the system into whatever state the app thinks is consistent. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
