On Tue, Dec 10, 2013 at 01:24:13PM -0500, Chris Mason wrote: > > It is there, 'btrfs subvol list -d /path', but I'd rather not let > > everybody parse output the output for a simple check. > > Aha ;) Yeah, that's what I was thinking. It's possible to find but hard > enough that nobody would be happy using it. Sorry I dont' udnerstand, you mean that the -d option is hard to find? > > Yeah it's natural and I guess it'll be the most frequent type of use. > > I've tried to think of the possible uses so we don't miss anything > > during design phase. > > > > Knowing the ID is necessary, the subvolume path is lost at deletion > > time, but let's say that the ID is available somehow, eg from > > application logs. > > > > I have a prototype for that, there's a separate subcommand to do just > > the waiting for a given subvolume list id to be cleaned up (but could > > be merged to fi sync if desired). It's built around the SEARCH ioctl and > > does not need kernel support. > > So the part where I think we agree is I don't think the kernel subvol > deletion ioctl should do the waiting. Yes, I've abandoned the kernel approach, for several reasons. > Exactly how the progs wait is a different question. BTRFS_IOC_START_SYNC + BTRFS_IOC_WAIT_SYNC I'll send out v2. -- 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
