On 2016-04-05 00:19, Duncan wrote:
Gareth Pye posted on Tue, 05 Apr 2016 13:44:05 +1000 as excerpted:
On Tue, Apr 5, 2016 at 12:37 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote:
1) It appears btrfs scrub start's -c option only takes numeric class,
so try -c3 instead of -c idle.
Does it count as a bug if it silently accepts the way I was doing it?
I've switched to -c3 and at least now the idle class listed in iotop is
idle, so I hope that means it will be more friendly to other processes.
I'd say yes, particularly given that the value must be the numeric class
isn't documented in the manpage at all.
Whether the bug is then one of documentation (say it must be numeric) or
of implementation (take the class name as well) is then up for debate.
I'd call fixing either one a fix. If it must be numeric, document that
(and optionally change the implementation to error in some way if a
numeric parameter isn't supplied for -c), else change the implementation
so the name can be taken as well (and optionally change the documentation
to explicitly mention that either one can be used). Doesn't matter to me
which.
In general, I'd say:
1. The documentation needs to be updated. Even if it's intended to
accept class names eventually, it should match the implementation.
2. The implementation needs error checking added. At the very least, it
should say something to the effect of "Hey, this doesn't work the way
you appear to think it does.", and possibly bail.
That said, I don't think there's a huge amount of value in adding the
ability to accept symbolic names. Nothing that I know of accepts them
on the command line, because most things pass the integer directly to
the syscall, thus allowing for people to use new classes (if any are
ever introduced) with old tools.
--
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
