Perché il mio dd è lento quando il blocco è piccolo?

Secondo gli articoli sul web, mount con nobarriervelocizzerà il disco:

1. Scrivi piccoli blocchi di dati su img (con barrier): LENTO

   # dd if=/dev/zero of=xfs.img bs=1024 count=20000
   # mkfs.xfs xfs.img
   # mkdir -p xfs
   # mount -o loop xfs.img xfs
   # dd if=/dev/zero of=output bs=32K count=1 conv=fsync
   32768 bytes (33 kB) copied,0.01037167 s, 2.4 MB/s
   

2. Scrivi piccoli blocchi di dati su img ( -o nobarrier): FAST

   # dd if=/dev/zero of=xfs.img bs=1024 count=20000
   # mkfs.xfs xfs.img
   # mkdir -p xfs
   # mount -o loop,nobarrier xfs.img xfs
   # cd xfs ; dd if=/dev/zero of=output bs=32K count=1 conv=fsync
   32768 bytes (33 kB) copied, 0.000608567 s, 53.8 MB/s
   

Ora, desidero rimontare il mio /per aggiungere la nobarrierbandiera. Quindi ho modificato /etc/fstab:

/dev/sda2      /      xfs     defaults,nobarrier    0    0

allora mount -o remount /.

Ma il risultato non è buono:

# pwd
/root
# dd if=/dev/zero of=output bs=32K count=1 conv=fsync
32768 bytes (33 kB) copied, 0.00811443 s, 4.0 MB/s

Non riesco a capire perché nobarrierfunzioni per dd-img, ma non per partizioni esistenti. Qualcuno può dirmelo?

Quando si utilizza un file system di loopback, è necessario tenere conto del file system su cui viene creato. In particolare, il kernel probabilmente non scaricherà immediatamente le pagine scritte del loopback FS sul disco del filesystem contenente, nonostante fsync sia chiamato sul loopback fs. Quelle scritture potrebbero essere syncd sul loopback, ma potrebbero rimanere come pagine sporche in memoria per il FS contenente.

Ora, il modo in cui l' nobarrieropzione interagisce con il driver di loopback, così come il filesystem contenente, è qualcosa di cui non sono sicuro. Come tale, ho fatto un esperimento. Ho aggiunto la variabile di montaggio del filesystem contenente con sync. I risultati sono i seguenti.

(tutte le uscite da dd if=/dev/zero of=xfs/output bs=32K count=10000 conv=fsync)

1. contenente fs async, loopbackbarrier

   32768000 bytes (33 MB) copied, 0.401873 s, 81.5 MB/s
   

2. contenente fs async, loopbacknobarrier

   32768000 bytes (33 MB) copied, 0.0414423 s, 791 MB/s
   

3. contenente fs sync, loopbackbarrier

   32768000 bytes (33 MB) copied, 71.5749 s, 458 kB/s
   

4. contenente fs sync, loopbacknobarrier

   32768000 bytes (33 MB) copied, 70.6415 s, 464 kB/s
   

Le velocità barriere nobarriervariano notevolmente quando è la fs contenente async. Tuttavia, quando la fs contenente è synce non beneficia della cache della pagina, lo speedup scompare per lo più.

La conclusione è che testare barriere nobarriercon un filesystem di loopback non sarà utile. L'interazione del filesystem contenente con la cache del kernel si metterà in mezzo. Ho il sospetto che la cache del kernel non sia l'unica cosa che causerà risultati errati durante il test delle prestazioni utilizzando loopback.

Fai attenzione a tali presupposti su Linux. Linux è stato ottimizzato per creare l'impressione della velocità rispetto ai filesystem invece di ottimizzare la velocità reale.

Il motivo per ottenere l'impressione di una velocità elevata è che i dati del file (in molti casi) non si trovano sul disco al termine del programma di scrittura. In altre parole, non puoi dire cosa hai misurato con il tuo test poiché non conosci lo stato del filesystem dopo che dd è finito.

Se si desidera ottenere risultati comparabili, è necessario impostare un test delle prestazioni che sia immune dal problema indicato, quindi è necessario scrivere un file che abbia almeno il doppio della RAM locale nel computer.