user hook for waiting for asynchronous BTRFS activities

[John Johansen]

On 11/16/2010 02:28 PM, David Nicol wrote:
> I have written and tested a patch, and gotten approval from Chris
> Mason for an ioctl number, that introduces a facility for waiting for
> certain asynchronous kernel-side activities: initially, subvolume
> deletion, but it seems like a general interface is in order.
> 
right if this could conceivably be applied to other filesystems then an
ioctl is not the right interface, a generic solution is needed.  We
already have mess with ioctls and snapshots, we really don't need another
ioctl mess with something that does waits for asynchronous events.  This
is something I would raise on fs-devel

> Ideally, this new feature and a forward-looking extension convention
> for the flags field (the ioctl takes two data, a timeout in
> milliseconds and flag bits) could get discussed here before getting
> included in ubuntu kernels and then going upstream.
> 
I'm not saying no, but generally the order is reversed, going upstream
or at least been presented to upstream before going into the ubuntu
kernels.  If a generic solution was presented to upstream right now
its unlikely it would hit .38, as it would need at least a few
revisions.

> My ideas concerning the flags field are as follows:
> 
> all zeroes: wait for pending subvolume deletions and nothing else
> 
> |1:  do not wait for subvolume deletions
> |2:  fail when there is an unexpected flag bit
> |4 and higher: set to enable waiting for other conditions. Currently
> the kcleaner_thread has two responsibilities, deleting subvolumes and
> writing out deferred inode data, so |4 will enable waiting for all
> deferred inode data to get written out, and |8 and up wait for other
> things to become asynchronous so they can be assigned to them.
> 
> Does that seem sound?
> 
Hrrmm, maybe.  What other uses beyond asynchronous subvolume deletion do
you see this being used for? Having a larger picture would help in
understanding the interface.

> Also, is it worth the effort to make ioctl tools work on both 32 and
> 64 bit systems, or is the standard practice that tools will work on
> one or the other? There are a lot of kernel data defined as "unsigned
> long."
> 
Yes and this is one of the reasons to avoid ioctls.  The for your user
space parameter vector the kernel won't do the conversion for you.  You
have to handle it yourself.

Generically there is no guarantee that the kernel and user space are even
running in the same mode.  ie. 32 bit userspace on 64 bit kernels and
64 bit user space on 32 bit kernels.  It may be odd, but it can happen.