Perché le letture da / dev / zero contano come IO_RBYTES?


25

Sto svuotando un disco rigido su alcuni SO Linux 4.x usando questo comando:

sudo sh -c 'pv -pterb /dev/zero > /dev/sda'

E ho aperto un altro tty e ho iniziato sudo htope notato questo:

  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

Il valore per IO_WBYTESsembra abbastanza normale, ma IO_RBYTESrimane a 4 KiB e non cambia mai.

Ho eseguito alcuni altri programmi, ad esempio

dd if=/dev/zero of=/dev/zero
cat /dev/zero > /dev/zero

ed è stato sorpreso di vedere nessuno di loro genera molto IO_RBYTESo IO_WBYTES.

Penso che questo non sia specifico per nessun programma, ma perché non legge /dev/zeroe scrive per /dev/{zero,null}contare come byte I / O?


5
Sono curioso, perché pensi che dovrebbero essere considerati I / O?
marzo

1
@marcelm Penso che qualsiasi input / output debba essere considerato I / O, inclusi file R / W, I / O di rete e molti altri.
iBug

ma tali operazioni eseguono I / O sull'hardware (rispettivamente il disco e la scheda di rete) e devono viaggiare su alcuni bus I / O (come PCI-express), che possono rappresentare un notevole collo di bottiglia. Scrive, diciamo, /dev/nullnon finendo per interfacciarsi con tale hardware e non ostruire i bus I / O. Portato all'estremo; sono anche le operazioni di lettura / scrittura nella / dalla memoria? Certo, non esiste una delineazione dura per queste cose, e tutto dipende da quale prospettiva prendi in queste cose e da quanto utile questa prospettiva ti finisce per essere.
marzo

1
Nota, il mio primo commento aveva lo scopo di provocare te (e altri) a pensare a quelle prospettive e scoprire perché stai prendendo la tua prospettiva. Non intendo insinuare che ti sbagli; Non penso nemmeno che la situazione sia quella in bianco e nero. Ma personalmente, sarei molto più interessato alle statistiche I / O sull'hardware reale (che potrebbe benissimo essere un collo di bottiglia) rispetto a /dev/{null,zero}(che di solito non è un collo di bottiglia). Questa è solo la mia prospettiva però :)
marzo

1
@marcelm Ma inizialmente pensavo che any read(2)e write(2)conta come I / O, il che è molto ragionevole nel suo senso.
iBug

Risposte:


54

Contano come I / O, ma non del tipo misurato dai campi che stai osservando.

In htop, IO_RBYTESe IO_WBYTESvisualizza read_bytese write_bytescampi da /proc/<pid>/io, e quei campi misurano byte che passano attraverso lo strato di blocco. /dev/zeronon coinvolge il livello di blocco, quindi le letture da esso non vengono visualizzate lì.

Per vedere l'I / O da /dev/zero, devi guardare i campi rchare wcharin /proc/<pid>/io, che appaiono in htopas RCHARe WCHAR:

rchar : personaggi letti

Il numero di byte che questa attività ha causato la lettura dalla memoria. Questa è semplicemente la somma dei byte a cui questo processo è passato read(2)e chiamate di sistema simili. Include elementi come l'I / O terminale e non è influenzato dalla necessità o meno dell'I / O del disco fisico effettivo (la lettura potrebbe essere stata soddisfatta da pagecache).

wchar : personaggi scritti

Il numero di byte che questa attività ha causato o deve causare la scrittura sul disco. Avvertenze simili si applicano qui come con rchar.

Vedi man 5 proce man 1 htopper i dettagli.


Quindi è rchare wcharche conta i byte da chiamate verso read(2)e write(2), giusto?
iBug

Sì, è giusto.
Stephen Kitt,

9
Parla di frasi fuorvianti sulla descrizione di rchar . Tutto ciò che è passato read()sicuramente non è "letto dalla memoria "!
ilkkachu,

2
Con @ilkkachu storagesi intendono "qualsiasi linea di bus concepibile", indipendentemente dal fatto che lo spazio di archiviazione in questione sia fisico o virtuale o mmap'd o un socket virtuale o nella cache L1 - è semplicemente qualcosa al di fuori della memoria mappata di quel programma, incluso il file condiviso
cat
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.