¿Acelerar la copia de 1000000 archivos pequeños?

Tengo 1000000 archivos de 4-20 kb en un directorio (puede generar archivos similares como este:seq 10000 | gzip > a; seq 1000000 | parallel --bar 'head -c{=$_=int(rand()*16)+4=}k a > {}' )

. Necesito copiar ese dir. Pero parece que tengo que hacer una búsqueda para cada archivo, así que esto lleva bastante tiempo.

¿Hay alguna manera de acelerar esto?

Actualmente estoy pensando que si pudiera obtener los bloques de disco que ocupan estos archivos, podría clasificarlos, fusionar los bloques que estaban cerca (dado que la lectura secuencial suele ser más rápida que la búsqueda) y leer estos bloques, para que estuvieran en la RAM. caché (tengo 32 GB de RAM) antes de hacer la copia.

Pero para que eso funcione, necesito una forma de identificar en qué bloques están los archivos.

Estoy usando EXT4 en un dispositivo magnético (es decir, no SSD).

Editar:

Esto debería funcionar pero no lo hace:

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'

Al probarlo en un archivo grande, no guarda el archivo en caché.

Edición 2:

Aquí hay algunos puntos de referencia. Se vació el caché (echo 3 >/proc/sys/vm/drop_caches ) entre cada ejecución. Mediciones realizadas 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

Entonces, ¿qué podemos aprender de eso?

Parece que ordenar por inodo es una buena idea. Pero parece paralelizar múltiples cp aumenta aún más el rendimiento. Vale la pena enfatizar que la fuente foo/ es un disco magnético, por lo que esto acaba con el mito de que la paralelización de E/S en un solo eje no acelerará la E/S:aquí, la paralelización clara y consistentemente acelera la copia.

Respuesta aceptada:

Suponiendo que

• entradas devueltas por readdir no están ordenados por número de inodo
• leer archivos en orden de inodo reduce el número de operaciones de búsqueda
• el contenido de la mayoría de los archivos está en la asignación inicial de 8k (una optimización ext4) que también debería generar menos operaciones de búsqueda

Relacionado:¿Rehacer archivos de miembro de registro y control en Oracle DB Standard Edition?

puede intentar acelerar la copia copiando archivos en orden de inodo.

Eso significa usar algo como esto:

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