On Tue, Jun 26, 2012 at 08:55:20PM -0500, David Nicol wrote:
> I've noticed that the patches I posted here two years ago about an
> ioctl to allow userspace to wait for deferred ops to complete aren't
> included in the "has all patches posted to mailing list" git repo. Is
> this an oversight or is there a problem with the proposed architecture
> or implementation?
I think the the "has all patches posted to mailing list" has an implicit
addendum "since btrfs-next has emerged". Your patch has higher chances
to be included into -next if you sent an updated version.
Your original proposal is limited to waiting for the cleaner thread,
which is one of those that cause stalled umounts and imho deserves more
finer control or status.
Simply waiting is not enough, I've seen cleaner or defrag on a root
subvol running for days. A way to cancel the operations would be more
useful here. This asks for a more generic interface for threads that do
not yet have their own control ioctls (like scrub or balance).
I've counted these:
* defrag - triggered by 'btrfs fi defrag'
* device add - this holds the uuid mutex and the same mutex is needed
for mkfs which blocks
* device del - dtto, plus it needs fully cancellable balance/relocation
* cleaner
* free space / inode cache writeout
the criterias are whether the operation blocks umount, ro-remount or
other filesystem-wide operations (like mkfs) or generally slows down the
throughput.
The set of operations on the threads:
* wait
* pause - eg. when cleaner activity is not desired atm
* cancel - either Ctrl-C/kill -9 or separate command via 'btrfs'
* resume - explicitly wake the thread and let it continue or just check
for work
* status - paused/active/idle
I don't know if you'd want to implement this in full, I guess not.
Besides this is yet in a RFC stage.
But I'll object to adding just the BTRFS_IOC_CLEANER_WAIT ioctl.
> Is the patch as seen there good, and were I to update it to apply
> against current source would there
> be any problem with tracking it for mainstream inclusion?
In it's current form, the patch looks like a prototype, not ready for
inclusion, IMHO.
david
--
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
