Re: waiting for deferred cleanup operations

silly gmail rich-text...

On Wed, Jun 27, 2012 at 1:42 PM, David Nicol [off-list ref] wrote:

On Wed, Jun 27, 2012 at 9:31 AM, David Sterba [off-list ref] wrote:

quoted

On Tue, Jun 26, 2012 at 08:55:20PM -0500, David Nicol wrote:

quoted

[let's discuss the] architecture

quoted

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

quoted

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

quoted

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?

quoted

* wait

  0: wait forever
  non-zero: wait that many ms

quoted

* pause - eg. when cleaner activity is not desired atm

 pause for that many ms, so 0 means until resumed

quoted

* cancel - either Ctrl-C/kill -9 or separate command via 'btrfs'

I don't see how "cancel" makes sense here

quoted

* 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,

quoted

* status - paused/active/idle

expands to two bits, one is there work and the other are we looking for
work (ha ha ha)