Re: Scrub priority, am I using it wrong?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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@cox.net> 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.