On Tue, 10 Nov 2009, Jeremy Fitzhardinge wrote: > On 11/10/09 14:13, Sage Weil wrote: > > On Tue, 10 Nov 2009, Andrey Kuzmin wrote: > > > > > >> On Tue, Nov 10, 2009 at 11:12 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > >> > >>> Hi all, > >>> > >>> This is an alternative approach to atomic user transactions for btrfs. > >>> The old start/end ioctls suffer from some basic limitations, namely > >>> > >>> - We can't properly reserve space ahead of time to avoid ENOSPC part > >>> way through the transaction, and > >>> - The process may die (seg fault, SIGKILL) part way through the > >>> transaction. Currently when that happens the partial transaction will > >>> commit. > >>> > >>> This patch implements an ioctl that lets the application completely > >>> specify the entire transaction in a single syscall. If the process gets > >>> killed or seg faults part way through, the entire transaction will still > >>> complete. > >>> > >>> The goal is to atomically commit updates to multiple files, xattrs, > >>> directories. But this is still a file system: we don't get rollback if > >>> things go wrong. Instead, do what we can up front to make sure things > >>> will work out. And if things do go wrong, optionally prevent a partial > >>> result from reaching the disk. > >>> > >> Why not snapshot respective root (doesn't work if transaction spans > >> multiple file-systems, but this doesn't look like a real-world > >> limitation), run txn against that snapshot and rollback on failure > >> instead? Snapshots are writable, cheap, and this looks like a real > >> transaction abort mechanism. > >> > > Good question. :) > > > > 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? > > > > If snapshots only capture what's currently physically on disk, then it > means that the transactions will be fairly heavyweight in requiring > everything to be physically synced. That may be what some apps want > anyway, but I can certainly imagine apps wanting transaction semantics > without having fsync-level durability requirements. Just to be clear, the transactions I'm talking about _only_ control the way operations are grouped when they commit to disk. They do not in any way affect the view of the file system that another concurrently running process might see. It's the application's responsibility to deal with the sort of transaction concurrency you're talking about. sage -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
