[Btrfs-devel] transaction ioctls

[Chris Mason]

On Tuesday 22 April 2008, Zach Brown wrote:
> > A misbehaving application could also deliberately hold a transaction
> > open, effectively locking up the FS, so it may make sense to restrict
> > something like this to root or something.
>
> I suspect it doesn't have to be deliberate.
>
> Have you tried this under memory pressure?  I wonder if the application
> can get stuck waiting for memory which will only be freed once the
> transaction closes.

This isn't as big an issue, btrfs doesn't pin pages while the transaction is 
running.  There is some accounting rbtrees that grow while the transaction is 
running, but it isn't like a reiserfsv3 or jbd that have physical blocks on 
disk pinned.

>
> I'm reasonably sure that we've discussed this persistent theoretical
> problem with these kinds of interfaces ;).

I do agree is isn't practical for anything other than a tightly controlled 
interface.  It might make sense to create specific ioctls or syscalls for the 
operations you need to combine.  Perhaps a generic mechanism that can link a 
bunch of async syscalls together within a single framework.

Ok, really though, I seem to remember that ceph needed to do file + xattr 
operations in one atomic shot, were there others?

-chris