Velocizza la copia di 1000000 piccoli file

Ho 1000000 file da 4-20 kb in una directory. Devo copiare quella cartella. Ma sembra che devo fare una ricerca per ogni file, quindi ci vuole un po 'di tempo.

C'è un modo in cui posso accelerarlo?

Attualmente sto pensando che se potessi ottenere i blocchi del disco che occupano questi file, potrei ordinarli, unire i blocchi che erano vicini (dato che la lettura sequenziale è spesso più veloce della ricerca) e leggere questi blocchi, in modo che fossero nella RAM cache (ho 32 GB di RAM) prima di fare la copia.

Ma affinché funzioni, ho bisogno di un modo per identificare su quali blocchi si trovano i file.

Sto usando EXT4 su un dispositivo magnetico (cioè non SSD).

Modificare:

Questo dovrebbe funzionare ma non:

ls |
parallel -IOO --pipe "sudo parallel -j100 hdparm --fibmap {}'|tail -n +5'" |
sort -nk 2 | 
perl -ane 'if($u+10000 < $F[1]) { print "$l ",($u-$l),"\n"; $l=$F[1] } $u=$F[2]' |
sudo parallel --colsep ' ' dd if=/dev/sda1 skip={1} bs=512 count={2} '| cat >/dev/null'

Durante il test su un file di grandi dimensioni, non memorizza nella cache il file.

Edit2:

Ecco alcuni parametri di riferimento. La cache è stata svuotata ( echo 3 >/proc/sys/vm/drop_caches) tra ogni esecuzione. Misure effettuate con iostats -dkx 5.

rsync -Hav foo/ bar/: 1800 KB/s
cp -a foo/ bar/: 3600 KB/s
cat sort-by-inode | parallel -j1 -X cp foo/{} bar/: 5000 KB/s
cat sort-by-inode | shuf | parallel -j1 -X cp foo/{} bar/: 3000 KB/s
cat sort-by-inode | shuf | parallel -j10 -X cp foo/{} bar/: 7000 KB/s
cat sort-by-inode | parallel -j10 -X cp foo/{} bar/: 8000 KB/s
cat sort-by-inode | parallel -j100 -X cp foo/{} bar/: 9000 KB/s
cat sort-by-inode | parallel -j500 -X cp foo/{} bar/: 10000 KB/s

Quindi cosa possiamo imparare da quello?

Sembra che l'ordinamento per inode sia una buona idea. Ma sembra che la parallelizzazione multipla cpaumenti ulteriormente le prestazioni. Vale la pena sottolineare che la sorgente foo/è un disco magnetico, quindi questo attacca il mito secondo cui parallelizzare l'I / O su un singolo mandrino non accelera l'I / O: parallelizzare in modo chiaro e coerente accelera la copia qui.

Supponendo che

• le voci restituite da readdirnon sono ordinate per numero di inode
• la lettura dei file in ordine di inode riduce il numero di operazioni di ricerca
• il contenuto della maggior parte dei file è nell'allocazione 8k iniziale (un'ottimizzazione ext4) che dovrebbe anche produrre meno operazioni di ricerca

puoi provare ad accelerare la copia copiando i file in ordine di inode.

Ciò significa usare qualcosa del genere:

$ cd /mnt/src
$ ls -U -i | sort -k1,1 -n | cut -d' ' -f2- > ~/clist
$ xargs cp -t /mnt2/dst < ~/clist

GNU tar- nella paxtradizione - gestisce da solo gli hardlink.

cd "$srcdir" ; tar --hard-dereference -cf - ./* |
    tar -C"${tgtdir}" -vxf -

In questo modo hai solo i due tarprocessi e non hai bisogno di continuare a invocare cpancora e ancora.

Analogamente alla risposta di @ maxschlepzig , è possibile analizzare l'output di filefragordinare i file nell'ordine in cui i loro primi frammenti appaiono sul disco:

find . -maxdepth 1 -type f |
  xargs -d'\n' filefrag -v |
  sed -n '
    /^   0:        0../ {
      s/^.\{28\}\([0-9][0-9]*\).*/\1/
      h
      }
    / found$/ {
      s/:[^:]*$//
      H
      g
      s/\n/ /p
      }' |
    sort -nk 1,1 |
    cut -d' ' -f 2- |
    cpio -p dest_dir

MMV con lo sedscript sopra , quindi assicurati di testare a fondo.

Altrimenti, qualunque cosa tu faccia, filefrag(parte di e2fsprogs) sarà molto più veloce da usare di hdparmquanto possa accettare più argomenti di file. Solo l'overhead della corsa hdparm1.000.000 di volte aggiungerà un sacco di overhead.

Inoltre, probabilmente non sarebbe così difficile scrivere uno perlscript (o un programma C) in un FIEMAP ioctlfile per ogni file, creare un array ordinato dei blocchi che dovrebbero essere copiati e dei file a cui appartengono e quindi copiare tutto in ordine per leggere la dimensione di ciascun blocco dal file corrispondente (fare attenzione a non esaurire i descrittori di file).