Lösung 1:
Aus dem Handbuch:
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.
Einheiten sind also in I/Os. Vielleicht weiß der Quellcode, was das bedeutet. Aus der Zusammenfassungsfunktionsdokumentation in time.c:
...
I == file system inputs (ru_inblock)
...
O == file system outputs (ru_oublock)
...
ru_inblock und ru_oblock kommen von getrusage. Aus dem Getrusage-Handbuch:
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.
Nun, das ist nicht besonders nützlich, aber LKML zeigt die diskutierten Patches (https://lkml.org/lkml/2007/3/19/100), um ru_inblock und ru_oublock hinzuzufügen:
As TASK_IO_ACCOUNTING currently counts bytes, we approximate blocks
count doing : nr_blocks = nr_bytes / 512
Eine Überprüfung des aktuellen Kernel-Quellcodes (https://github.com/spotify/linux/blob/master/include/linux/task_io_accounting_ops.h) zeigt:
/*
* 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;
}
und
/*
* 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;
}
Kurz gesagt, ja, Blöcke sind jeweils ungefähr 512 Bytes groß.
Lösung 2:
Ich würde raten Die "Ein-/Ausgaben des Dateisystems" bedeuten die Blockgröße. Wenn also das zugrunde liegende Dateisystem mit 512-Byte-Blöcken formatiert wurde, gibt es das zurück, wenn etwas anderes, dann das.
Aber das ist nur eine Vermutung.