Solution 1 :
Du manuel :
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.
Les unités sont donc en E/S. Peut-être que le code source sait ce que cela signifie. À partir de la documentation de la fonction de résumé dans time.c :
...
I == file system inputs (ru_inblock)
...
O == file system outputs (ru_oublock)
...
ru_inblock et ru_oblock proviennent de getrusage. Extrait du manuel 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.
Eh bien, ce n'est pas particulièrement utile, mais LKML montre les correctifs en cours de discussion (https://lkml.org/lkml/2007/3/19/100) pour ajouter ru_inblock et ru_oublock :
As TASK_IO_ACCOUNTING currently counts bytes, we approximate blocks
count doing : nr_blocks = nr_bytes / 512
Une vérification du code source actuel du noyau (https://github.com/spotify/linux/blob/master/include/linux/task_io_accounting_ops.h) indique :
/*
* 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;
}
et
/*
* 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 bref, oui, les blocs font environ 512 octets chacun.
Solution 2 :
Je vais deviner les "entrées/sorties du système de fichiers" signifient la taille du bloc, donc si le système de fichiers sous-jacent a été formaté avec des blocs de 512 octets, il renvoie cela, si quelque chose d'autre, alors cela.
Mais ce n'est qu'une supposition.