ionice in FreeBSD?

[jhell]

On Mon, 8 Feb 2010 23:37, mv@ wrote:
> On 3/02/2010 10:52 PM, Jordi Espasa Clofent wrote:
>> On 02/03/2010 12:12 PM, Bruce Simpson wrote:
>>> On 02/02/2010 17:19, Jordi Espasa Clofent wrote:
>>>> 
>>>> In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if
>>>> I'm understanding correctly, they're related to CPU priorty only, not
>>>> to I/O.
>>> 
>>> That's not entirely true.
>>> 
>>> A thread's CPU priority is still going to affect its ability to be
>>> scheduled on the CPU, and if it's waiting in the read() or write()
>>> syscalls, then this will make a difference to how quickly it can
>>> complete the next call.
>> 
>> Yes. I've already supposed it.
>> 
>>> However, it doesn't explicitly affect relative I/O prioritization. This
>>> is another story entirely. I suspect in a lot of cases adding a weight
>>> to per thread I/O, isn't going to make much difference for disk I/Os
>>> which are being sorted for the geometry (e.g. AHCI NCQ).
>>> 
>>> So I guess my question is, 'why do you need I/O scheduling, and what
>>> aspect of system performance are you trying to solve with it' ?
>> 
>> Some shell-scripts based on dd or rsync, for example. Even a daily 
>> antivirus (ClamAV) scanner means an extensive I/O.
>> 
> Programs like Rsync do provide --bwlimit= which work great in slowing it down 
> to a desired level.
>
> I can't help but think every program that can use too much IO should have 
> it's own IO/speed switch of some sort.
> I can only hope that in general nix evolution that all programs that can over 
> use IO will offer a switch to slow it down like Rsync does.
>
> Using a while ionice can be a useful feature it can also be said that there 
> are too many instances where it's being used as a hack to deal with a program 
> that isn't offering all the functionality that it should.
>
> Cheers,
> Mike
>

In this thread with due respect to the OP the following might be 
considered a fruitless hack but it works!.

Piping a processes output to dd(1) if you have a choice is a pretty fair 
temporary solution if a program does not offer that capability.

For instance, I don't know if you are familiar with dump(8) at all, but I 
use a -P or pipe from that process to dd(8) to slow down the traffic that 
it tries to write over the network for backup purposes and then also give 
dump(8) a different nice level so it plays along.

So even if you can cat your output and then read it in from fd(4) using 
dd(8) you still have a chance at slowing things down a little or writing 
at smaller increments that wont impact your environment as hard.

;)

-- 

  jhell