Note que minha resposta assume que você está usando o Linux, pois tenho certeza que o comando ionice é específico do Linux.
O agendador de E / S opera na camada de bloco, não na camada do sistema de arquivos. Como resultado, isso afeta apenas os dispositivos de armazenamento locais e o armazenamento em block conectado remotamente (como dispositivos de armazenamento conectados NBD, iSCSI ou ATAoE). Como resultado, não há planejamento de E / S especial para um compartilhamento NFS no cliente NFS (mas o servidor ainda faz isso, ele simplesmente não sabe sobre as prioridades de E / S remotas), mas pode ser para iSCSI, Dispositivos NBD, ou ATAoE (muitas distros irão configurá-los com o agendador sem operação, o que significa que o único agendamento de I / O é feito no lado do servidor aqui também). O único caso possível em que isso afetaria o NFS é se você estiver usando pNFS com o layout de bloco, mas provavelmente não é nada e não tenho certeza de como isso interage com a camada de bloco, então vou ignorar isso ).
Com relação ao que a prioridade de E / S realmente faz , isso depende do planejador de E / S específico que você está usando. No mínimo, os escalonadores noop e deadline (e possivelmente os novos mq-deadline) não prestam atenção em nada, enquanto CFQ, BFQ e eu achamos que o novo agendador Kyber faz algo com ele, mas eles não fazem isso. Não faça exatamente as mesmas coisas com ele. Tanto quanto eu sei, para CFQ, as classes se comportam de forma semelhante às classes de escalonamento de CPU equivalentes (com a classe de E / S em tempo real se comportando como a classe de escalonamento de CPU FIFO RT). Eu acredito que o BFQ apenas os usa como dicas para o seu algoritmo de programação (em oposição ao impacto mais significativo que eles têm com o CFQ), mas não tenho certeza sobre isso.
Agora, com relação ao seu exemplo específico, ionice não deve ter nenhum impacto, mas provavelmente não teria muito impacto em um sistema de arquivos local, a menos que o disco já estivesse totalmente utilizado por outros processos (o 'ocioso'). A classe de agendamento especificada não é um verdadeiro agendador ocioso, mas, mesmo que fosse, find não usa muito tempo de disco na maioria das vezes, e o comando rm usa ainda menos).
Além disso, uma nota lateral ligeiramente fora do tópico, mas o comando find que você citou removerá apenas os arquivos (por causa da opção -type f ), portanto não é exatamente equivalente a rm -rf e você pode melhorar (local), substituindo o -exec rm {} ; por -delete , que faz a mesma coisa sem precisar criar um novo processo para cada arquivo que está excluindo.