Mempercepat Penyalinan 1000000 File Kecil?

Saya memiliki 1000000 file 4-20 kb dalam dir (Anda dapat membuat file serupa seperti ini:seq 10000 | gzip > a; seq 1000000 | parallel --bar 'head -c{=$_=int(rand()*16)+4=}k a > {}' )

. Saya perlu menyalin dir itu. Tapi sepertinya saya harus mencari setiap file jadi ini memakan waktu cukup lama.

Apakah ada cara agar saya bisa mempercepat ini?

Saat ini saya berpikir bahwa jika saya bisa mendapatkan blok disk yang ditempati file-file ini, saya bisa mengurutkannya, menggabungkan blok yang dekat (mengingat bahwa membaca berurutan seringkali lebih cepat daripada mencari) dan membaca blok ini, sehingga mereka berada di RAM cache (saya punya RAM 32 GB) sebelum menyalin.

Tetapi agar itu berfungsi, saya memerlukan cara untuk mengidentifikasi blok mana yang berisi file.

Saya menggunakan EXT4 pada perangkat magnetik (bukan SSD).

Sunting:

Ini seharusnya berhasil tetapi tidak:

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'

Saat mengujinya pada file besar, file tersebut tidak di-cache.

Sunting2:

Berikut adalah beberapa benchmark. Cache telah dihapus (echo 3 >/proc/sys/vm/drop_caches ) antara setiap lari. Pengukuran dilakukan dengan 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

Jadi apa yang bisa kita pelajari dari itu?

Tampaknya mengurutkan berdasarkan inode adalah ide yang bagus. Tapi sepertinya memparalelkan beberapa cp meningkatkan kinerja lebih jauh. Perlu ditekankan bahwa sumber foo/ adalah disk magnetik, jadi ini menyerang mitos bahwa memparalelkan I/O ke satu spindel tidak akan mempercepat I/O:Memparalelkan dengan jelas dan konsisten mempercepat penyalinan di sini.

Jawaban yang Diterima:

Dengan asumsi bahwa

• entri dikembalikan oleh readdir tidak diurutkan berdasarkan nomor inode
• membaca file dalam urutan inode mengurangi jumlah operasi pencarian
• konten sebagian besar file berada dalam alokasi awal 8k (pengoptimalan ext4) yang juga akan menghasilkan lebih sedikit operasi pencarian

Terkait:Ulangi log anggota dan file kontrol di Oracle DB Standard Edition?

Anda dapat mencoba mempercepat penyalinan melalui penyalinan file dalam urutan inode.

Itu berarti menggunakan sesuatu seperti ini:

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