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? The proposed architecture is, there is an IOCTL to wait for deferred activity to complete, and it takes a flag field listing possible deferred activities that are being waited for. Only one was defined in the submitted patch, to wait for completion of removal of dead trees, with the hope that future deferred things would register a bit with the ... The whole picture is in the introduction to the last submitted version of the patch, http://permalink.gmane.org/gmane.comp.file-systems.btrfs/8668 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? David Nicol -- Run it up the flagpole and see who salutes it -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I see that the #undef spells the macro wrong, so I''ll fix that of course too. On Tue, Jun 26, 2012 at 8:55 PM, David Nicol <davidnicol@gmail.com> wrote:> The whole picture is in the introduction to the last submitted version > of the patch, > http://permalink.gmane.org/gmane.comp.file-systems.btrfs/8668-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
silly gmail rich-text... On Wed, Jun 27, 2012 at 1:42 PM, David Nicol <davidnicol@gmail.com> wrote:> > > > On Wed, Jun 27, 2012 at 9:31 AM, David Sterba <dave@jikos.cz> wrote: >> >> On Tue, Jun 26, 2012 at 08:55:20PM -0500, David Nicol wrote: >> > [let''s discuss the] architecture > > >> >> 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. >> > > Five subsystems at one bit each > > >> >> 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 > > > Five mutually exclusive action codes : three bits, allowing three reserved > action codes > > >> >> I don''t know if you''d want to implement this in full, I guess not. > > > Sure! In fact it could even be backwards-compatible with the proposed bit > protocol, mostly. The installed base is AFAIK all under one administration, > so backwards-compatibility isn''t that important. > > The new protocol could be made which would be clearer: > > Three bits for action code, > five bits for subsystem selection, > one bit for strict mask parsing (is this a YAGNI or a BCP?) > Remaining 23 bits reserved for future subsystems. > > Or would it be better to only affect one subsystem at a time, and if so > why? I think the mask approach is better, that we want fewer ioctl calls, > but may be wrong. > > And how does the timer field affect each of the five commands? >> >> * wait > > 0: wait forever > non-zero: wait that many ms > >> >> * pause - eg. when cleaner activity is not desired atm > > pause for that many ms, so 0 means until resumed > >> >> * cancel - either Ctrl-C/kill -9 or separate command via ''btrfs'' > > I don''t see how "cancel" makes sense here > > >> >> * resume - explicitly wake a paused thread and let it continue or just >> check for work > > > Hmm. if resume is only the opposite of pause, and we''re at system (not > thread) granularity, there could be another check verb, that is > informational -- that''s the status -- does a paused thread check for its > work? could the timeout value on a pause indicate some kind of desperation > metric leading to unpausing, or just mean pause for so many ms > > if paused threads still check but don''t do, > >> >> * status - paused/active/idle > > > expands to two bits, one is there work and the other are we looking for > work (ha ha ha) >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html