Pourquoi ne lit-il pas à partir de / dev / zero comme IO_RBYTES?
Je vide un disque dur sur un système d'exploitation Linux 4.x à l'aide de cette commande:
Sudo sh -c 'pv -pterb /dev/zero > /dev/sda'
Et j'ai ouvert un autre tty et commencé Sudo htop et j'ai remarqué ceci:
PID USER PRI NI CPU% RES SHR IO_RBYTES IO_WBYTES S TIME+ Command
4598 root 20 0 15.5 1820 1596 4096 17223823 D 1:14.11 pv -pterb /dev/zero
La valeur de IO_WBYTES semble tout à fait normal, mais IO_RBYTES reste à 4 Ko et ne change jamais.
J'ai exécuté quelques autres programmes, par exemple
dd if=/dev/zero of=/dev/zero
cat /dev/zero > /dev/zero
et a été surpris de voir qu'aucun d'eux ne génère beaucoup de IO_RBYTES ou IO_WBYTES.
Je pense que cela n'est spécifique à aucun programme, mais pourquoi ne lit-il pas à partir de /dev/zero et écrit dans /dev/{zero,null} compte comme octets d'E/S?
Ils comptent comme des E/S, mais pas du type mesuré par les champs que vous regardez.
Dans htop, IO_RBYTES Et IO_WBYTES Affichez les champs read_bytes Et write_bytes De /proc/<pid>/io, Et ces champs mesurent les octets qui traversent la couche de blocs. /dev/zero N'implique pas la couche de blocs, donc les lectures ne s'affichent pas là-bas.
Pour voir les E/S de /dev/zero, Vous devez regarder les champs rchar et wchar dans /proc/<pid>/io, Qui apparaissent dans htop as RCHAR et WCHAR:
rchar : caractères lus
Le nombre d'octets que cette tâche a provoqué à lire à partir du stockage. Il s'agit simplement de la somme des octets que ce processus a transmis à
read(2)et des appels système similaires. Il inclut des éléments tels que les E/S du terminal et n'est pas affecté par la nécessité ou non des E/S de disque physique réelles (la lecture peut avoir été satisfaite à partir de la mise en cache).wchar : caractères écrits
Le nombre d'octets que cette tâche a provoqué ou doit faire écrire sur le disque. Des mises en garde similaires s'appliquent ici comme avec rchar.
Voir man 5 proc et man 1 htop pour plus de détails.