Solución 1:
Del manual:
The `%I' and `%O' values are allegedly only `real'
input and output and do not include those supplied
by caching devices. The meaning of `real' I/O reported
by `%I' and `%O' may be muddled for workstations,
especially diskless ones.
Entonces las unidades están en E/S. Quizás el código fuente sepa lo que eso significa. De la documentación de la función de resumen en time.c:
...
I == file system inputs (ru_inblock)
...
O == file system outputs (ru_oublock)
...
ru_inblock y ru_oblock provienen de getrusage. Del manual de getrusage:
ru_inblock (since Linux 2.6.22)
The number of times the filesystem had to perform input.
ru_oublock (since Linux 2.6.22)
The number of times the filesystem had to perform output.
Bueno, eso no es particularmente útil, pero LKML muestra los parches que se están discutiendo (https://lkml.org/lkml/2007/3/19/100) para agregar ru_inblock y ru_oublock:
As TASK_IO_ACCOUNTING currently counts bytes, we approximate blocks
count doing : nr_blocks = nr_bytes / 512
Una verificación del código fuente actual del kernel (https://github.com/spotify/linux/blob/master/include/linux/task_io_accounting_ops.h) muestra:
/*
* We approximate number of blocks, because we account bytes only.
* A 'block' is 512 bytes
*/
static inline unsigned long task_io_get_inblock(const struct task_struct *p)
{
return p->ioac.read_bytes >> 9;
}
y
/*
* We approximate number of blocks, because we account bytes only.
* A 'block' is 512 bytes
*/
static inline unsigned long task_io_get_oublock(const struct task_struct *p)
{
return p->ioac.write_bytes >> 9;
}
En resumen, sí, los bloques tienen aproximadamente 512 bytes cada uno.
Solución 2:
Yo supongo las "entradas/salidas del sistema de archivos" significan el tamaño del bloque, por lo que si el sistema de archivos subyacente ha sido formateado con bloques de 512 bytes, devuelve eso, si es algo más, entonces eso.
Pero esto es solo una suposición.