Resposta curta, nenhuma que eu saiba.
vmstat (execute vmstat 1 para ter uma idéia imediata do que ele faz; ^C para sair) pode mostrar o uso de IO sistema completo ( BI e BO colunas, blocos e blocos, provavelmente são mais imediatamente úteis). Eu acho isso muito útil em sistemas quase silenciosos.
strace (execute strace -o /tmp/ls ls /tmp ; em seguida, examine o arquivo /tmp/ls para ver quais dados ele fornece) permite que você siga o caminho de execução de seu programa por todas as chamadas write () e adicione o solicitado tamanhos para qualquer descritor de arquivo que você está interessado. No lado positivo, ele poderia ser script e seria especificamente para esse programa para esse arquivo. No lado negativo, isso diminuiria a execução do seu programa (talvez ele rodasse muito lentamente), e perderia completamente todo o IO do disco que usa regiões de memória mmap(2) .
Você poderia escrever uma biblioteca que você carregaria com a variável de ambiente LD_PRELOAD para substituir read(2) e write(2) por wrappers que executassem sua contabilidade e acabasse chamando as chamadas do sistema (isso certamente não vale o incômodo) . Também falhará ao ver o disco IO que usa mmap(2) . Você teria que ter uma boa razão para seguir esse caminho.
Você pode escrever um back-end FUSE para fazer sua contabilidade. Seria lento e diminuiria todos os processos usando esse sistema de arquivos. O código FUSE também expõe muitas partes internas do kernel que esperam resultados rápidos para atrasos arbitrariamente longos (e glacialmente longos, por padrões de kernel) devido a programas de espaço do usuário. Programas podem causar pressão de memória, troca e mais tráfego de disco. O FUSE é melhor implantado em ambientes com memória abundante, requisitos não reais e baixo custo de falha.