Buona dimensione del blocco per la clonazione del disco con diskdump (dd)

64k sembra essere una buona scelta:

Results:

  no bs=        78s     144584+0 records
  bs=512        78s     144584+0 records
  bs=1k         38s     72292+0 records
  bs=2k         38s     36146+0 records
  bs=4k         38s     18073+0 records
  bs=5k         39s     14458+1 records
  bs=50k        38s     1445+1 records
  bs=500k       39s     144+1 records
  bs=512k       39s     144+1 records
  bs=1M         39s     72+1 records
  bs=5M         39s     14+1 records
  bs=10M        39s     7+1 records

(tratto da qui).

questo corrisponde alle mie scoperte riguardo al buffering di lettura/scrittura per velocizzare un programma di conversione pesante io che una volta sfruttavo @work.

dd copierà felicemente usando il BS di qualunque cosa tu voglia, e copierà un blocco parziale (alla fine).

Fondamentalmente, il parametro block size (bs) sembra impostare la quantità di memoria utilizzata per leggere in blocco da un disco prima di provare a scrivere quel blocco sull'altro.

Se hai molta RAM, rendere la BS grande (ma interamente contenuta nella RAM) significa che il sottosistema I/O viene utilizzato il più possibile eseguendo letture e scritture di grandi dimensioni, sfruttando la RAM. Rendere piccolo il BS significa che l'overhead di I/O come proporzione dell'attività totale aumenta.

Naturalmente in questo c'è una legge di rendimenti decrescenti. La mia approssimazione approssimativa è che una dimensione del blocco nell'intervallo da 128K a 32M probabilmente fornirà prestazioni tali che i costi generali sono piccoli rispetto al semplice I/O e aumentare non farà molta differenza. Il motivo per cui il limite inferiore va da 128K a 32M è che dipende dal sistema operativo, dall'hardware e così via.

Se fossi in me, farei alcuni esperimenti cronometrando una copia/clone usando un BS di 128K e ancora usando (diciamo) 16M. Se uno è notevolmente più veloce, usalo. In caso contrario, usa la BS più piccola delle due.

Come altri hanno già detto, non esiste una dimensione del blocco universalmente corretta; ciò che è ottimale per una situazione o un componente hardware può essere terribilmente inefficiente per un'altra. Inoltre, a seconda dello stato dei dischi, potrebbe essere preferibile utilizzare una dimensione del blocco diversa da quella "ottimale".

Una cosa abbastanza affidabile sull'hardware moderno è che la dimensione del blocco predefinita di 512 byte tende ad essere quasi un ordine di grandezza più lenta di un'alternativa più ottimale. In caso di dubbio, ho scoperto che 64K è un valore predefinito moderno piuttosto solido. Sebbene 64K di solito non sia LA dimensione ottimale del blocco, nella mia esperienza tende ad essere molto più efficiente dell'impostazione predefinita. 64K ha anche una storia piuttosto solida di prestazioni affidabili:puoi trovare un messaggio dalla mailing list Eug-Lug, circa 2002, che raccomanda una dimensione del blocco di 64K qui:http://www.mail-archive.com/example@ unixlinux.online/msg12073.html

Per determinare LA dimensione ottimale del blocco di output, ho scritto il seguente script che verifica la scrittura di un file di test di 128 M con dd in una gamma di diverse dimensioni di blocco, dall'impostazione predefinita di 512 byte a un massimo di 64 M. Attenzione, questo script usa dd internamente, quindi usalo con cautela.

dd_obs_test.sh:

#!/bin/bash

# Since we're dealing with dd, abort if any errors occur
set -e

TEST_FILE=${1:-dd_obs_testfile}
TEST_FILE_EXISTS=0
if [ -e "$TEST_FILE" ]; then TEST_FILE_EXISTS=1; fi
TEST_FILE_SIZE=134217728

if [ $EUID -ne 0 ]; then
  echo "NOTE: Kernel cache will not be cleared between tests without sudo. This will likely cause inaccurate results." 1>&2
fi

# Header
PRINTF_FORMAT="%8s : %s\n"
printf "$PRINTF_FORMAT" 'block size' 'transfer rate'

# Block sizes of 512b 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M
for BLOCK_SIZE in 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864
do
  # Calculate number of segments required to copy
  COUNT=$(($TEST_FILE_SIZE / $BLOCK_SIZE))

  if [ $COUNT -le 0 ]; then
    echo "Block size of $BLOCK_SIZE estimated to require $COUNT blocks, aborting further tests."
    break
  fi

  # Clear kernel cache to ensure more accurate test
  [ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches

  # Create a test file with the specified block size
  DD_RESULT=$(dd if=/dev/zero of=$TEST_FILE bs=$BLOCK_SIZE count=$COUNT conv=fsync 2>&1 1>/dev/null)

  # Extract the transfer rate from dd's STDERR output
  TRANSFER_RATE=$(echo $DD_RESULT | \grep --only-matching -E '[0-9.]+ ([MGk]?B|bytes)/s(ec)?')

  # Clean up the test file if we created one
  if [ $TEST_FILE_EXISTS -ne 0 ]; then rm $TEST_FILE; fi

  # Output the result
  printf "$PRINTF_FORMAT" "$BLOCK_SIZE" "$TRANSFER_RATE"
done

Visualizza su GitHub

Ho testato questo script solo su un sistema Debian (Ubuntu) e su OSX Yosemite, quindi probabilmente ci vorranno alcune modifiche per farlo funzionare su altri tipi di Unix.

Per impostazione predefinita, il comando creerà un file di test denominato dd_obs_testfile nella directory corrente. In alternativa, puoi fornire un percorso a un file di test personalizzato fornendo un percorso dopo il nome dello script:

$ ./dd_obs_test.sh /path/to/disk/test_file

L'output dello script è un elenco delle dimensioni dei blocchi testati e dei rispettivi trasferimenti in questo modo:

$ ./dd_obs_test.sh
block size : transfer rate
       512 : 11.3 MB/s
      1024 : 22.1 MB/s
      2048 : 42.3 MB/s
      4096 : 75.2 MB/s
      8192 : 90.7 MB/s
     16384 : 101 MB/s
     32768 : 104 MB/s
     65536 : 108 MB/s
    131072 : 113 MB/s
    262144 : 112 MB/s
    524288 : 133 MB/s
   1048576 : 125 MB/s
   2097152 : 113 MB/s
   4194304 : 106 MB/s
   8388608 : 107 MB/s
  16777216 : 110 MB/s
  33554432 : 119 MB/s
  67108864 : 134 MB/s

(Nota:l'unità delle velocità di trasferimento varia a seconda del sistema operativo)

Per testare la dimensione ottimale del blocco di lettura, potresti usare più o meno lo stesso processo, ma invece di leggere da /dev/zero e scrivere sul disco, dovresti leggere dal disco e scrivere su /dev/null. Uno script per fare ciò potrebbe essere così:

dd_ibs_test.sh:

#!/bin/bash

# Since we're dealing with dd, abort if any errors occur
set -e

TEST_FILE=${1:-dd_ibs_testfile}
if [ -e "$TEST_FILE" ]; then TEST_FILE_EXISTS=$?; fi
TEST_FILE_SIZE=134217728

# Exit if file exists
if [ -e $TEST_FILE ]; then
  echo "Test file $TEST_FILE exists, aborting."
  exit 1
fi
TEST_FILE_EXISTS=1

if [ $EUID -ne 0 ]; then
  echo "NOTE: Kernel cache will not be cleared between tests without sudo. This will likely cause inaccurate results." 1>&2
fi

# Create test file
echo 'Generating test file...'
BLOCK_SIZE=65536
COUNT=$(($TEST_FILE_SIZE / $BLOCK_SIZE))
dd if=/dev/urandom of=$TEST_FILE bs=$BLOCK_SIZE count=$COUNT conv=fsync > /dev/null 2>&1

# Header
PRINTF_FORMAT="%8s : %s\n"
printf "$PRINTF_FORMAT" 'block size' 'transfer rate'

# Block sizes of 512b 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M
for BLOCK_SIZE in 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864
do
  # Clear kernel cache to ensure more accurate test
  [ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches

  # Read test file out to /dev/null with specified block size
  DD_RESULT=$(dd if=$TEST_FILE of=/dev/null bs=$BLOCK_SIZE 2>&1 1>/dev/null)

  # Extract transfer rate
  TRANSFER_RATE=$(echo $DD_RESULT | \grep --only-matching -E '[0-9.]+ ([MGk]?B|bytes)/s(ec)?')

  printf "$PRINTF_FORMAT" "$BLOCK_SIZE" "$TRANSFER_RATE"
done

# Clean up the test file if we created one
if [ $TEST_FILE_EXISTS -ne 0 ]; then rm $TEST_FILE; fi

Visualizza su GitHub

Una differenza importante in questo caso è che il file di test è un file scritto dallo script. Non puntare questo comando su un file esistente o il file esistente verrà sovrascritto con dati casuali!

Per il mio particolare hardware ho scoperto che 128K era la dimensione del blocco di input ottimale su un HDD e 32K era la dimensione ottimale su un SSD.

Sebbene questa risposta copra la maggior parte delle mie scoperte, mi sono imbattuto in questa situazione abbastanza volte che ho scritto un post sul blog a riguardo:http://blog.tdg5.com/tuning-dd-block-size/ Puoi trovare più specifiche sui test che ho eseguito lì.

Anche questo post di StackOverflow può essere utile:dd:How to calcolate la dimensione del blocco ottimale?