[Btrfs-devel] transaction ioctls

[Sage Weil]

On Tue, 22 Apr 2008, Chris Mason wrote:
> I'm definitely willing to include it for you to experiment with.  Holding a 
> transaction from userland can indeed lead to deadlock, but in this case your 
> userland basically owns the server anyway.  I'm worried about some nasty 
> corner cases still, but btrfs is blissfully ignoring those right now anyway.
> 
> One problem will be operations that are basically boundless (truncating a 
> file, large writes).  Eventually the ENOSPC support will hook into the 
> transaction system to make sure a given operation reserves enough free space.
> 
> With your ioctls, the "do a bunch of stuff" will need to honor the same 
> accounting rules as the kernel code (which don't exist yet).

So, if the transaction start ioctl made a space reservation, and if _all_ 
fs ops were wrapped by such reservations, that should avoid ENOSPC, yeah?

That's doesn't really help with the memory pressure issue, though.  :(

> I thought your original plan was to do all of this from userland (without a 
> kernel filesystem at all)?  The btrfs progs share most of the same code with 
> the kernel, so with a little love to the transaction and IO subsystems, you'd 
> be able to use it as a library style DB.

Yeah...  The issue is just that "a little love" is significantly more love 
than this handful of ioctls, and I'm a little wary of getting into it.  
That does seem like a better long term solution, though.

sage