- Ubuntu 14.04 di desktop
- Source Drive: / dev / sda1: 5TB
volume drive tunggal ext4 - Volume Target: / dev / mapper / archive-lvarchive: raid6 (mdadm) volume 18TB dengan
partisi lvm dan ext4
Ada sekitar 15 juta file untuk dipindahkan, dan beberapa mungkin merupakan duplikat (saya tidak ingin menimpa duplikat).
Perintah yang digunakan (dari direktori sumber) adalah:
ls -U |xargs -i -t mv -n {} /mnt/archive/targetDir/{}
Ini telah berlangsung selama beberapa hari seperti yang diharapkan, tetapi saya mendapatkan kesalahan dalam peningkatan frekuensi. Ketika mulai drive target sekitar 70% penuh, sekarang sekitar 90%. Dulu sekitar 1/200 dari gerakan akan menyatakan dan kesalahan, sekarang sekitar 1/5. Tidak ada file yang lebih dari 100 MB, kebanyakan sekitar 100 ribu
Beberapa info:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb3 155G 5.5G 142G 4% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 797M 2.9M 794M 1% /run
none 5.0M 4.0K 5.0M 1% /run/lock
none 3.9G 0 3.9G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/sdb1 19G 78M 18G 1% /boot
/dev/mapper/archive-lvarchive 18T 15T 1.8T 90% /mnt/archive
/dev/sda1 4.6T 1.1T 3.3T 25% /mnt/tmp
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb3 10297344 222248 10075096 3% /
none 1019711 4 1019707 1% /sys/fs/cgroup
udev 1016768 500 1016268 1% /dev
tmpfs 1019711 1022 1018689 1% /run
none 1019711 5 1019706 1% /run/lock
none 1019711 1 1019710 1% /run/shm
none 1019711 2 1019709 1% /run/user
/dev/sdb1 4940000 582 4939418 1% /boot
/dev/mapper/archive-lvarchive 289966080 44899541 245066539 16% /mnt/archive
/dev/sda1 152621056 5391544 147229512 4% /mnt/tmp
Inilah hasil saya:
mv -n 747265521.pdf /mnt/archive/targetDir/747265521.pdf
mv -n 61078318.pdf /mnt/archive/targetDir/61078318.pdf
mv -n 709099107.pdf /mnt/archive/targetDir/709099107.pdf
mv -n 75286077.pdf /mnt/archive/targetDir/75286077.pdf
mv: cannot create regular file ‘/mnt/archive/targetDir/75286077.pdf’: No space left on device
mv -n 796522548.pdf /mnt/archive/targetDir/796522548.pdf
mv: cannot create regular file ‘/mnt/archive/targetDir/796522548.pdf’: No space left on device
mv -n 685163563.pdf /mnt/archive/targetDir/685163563.pdf
mv -n 701433025.pdf /mnt/archive/targetDir/701433025.pd
Saya telah menemukan BANYAK posting tentang kesalahan ini, tetapi prognosisnya tidak sesuai. Masalah seperti "drive Anda sebenarnya penuh" atau "Anda kehabisan inode" atau bahkan "volume / boot Anda penuh". Namun, sebagian besar, mereka berurusan dengan perangkat lunak pihak ke-3 yang menyebabkan masalah karena cara menangani file, dan semuanya konstan, artinya SETIAP gerakan gagal.
Terima kasih.
EDIT: di sini adalah contoh file gagal dan berhasil:
GAGAL (masih di drive sumber)
ls -lhs 702637545.pdf
16K -rw-rw-r-- 1 myUser myUser 16K Jul 24 20:52 702637545.pdf
SUCCEEDED (Pada volume target)
ls -lhs /mnt/archive/targetDir/704886680.pdf
104K -rw-rw-r-- 1 myUser myUser 103K Jul 25 01:22 /mnt/archive/targetDir/704886680.pdf
Selain itu, walaupun tidak semua file gagal, file yang gagal akan SELALU gagal. Jika saya coba lagi dan lagi itu konsisten.
EDIT: Beberapa perintah tambahan per permintaan oleh @mjturner
$ ls -ld /mnt/archive/targetDir
drwxrwxr-x 2 myUser myUser 1064583168 Aug 10 05:07 /mnt/archive/targetDir
$ tune2fs -l /dev/mapper/archive-lvarchive
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name: <none>
Last mounted on: /mnt/archive
Filesystem UUID: af7e7b38-f12a-498b-b127-0ccd29459376
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 289966080
Block count: 4639456256
Reserved block count: 231972812
Free blocks: 1274786115
Free inodes: 256343444
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 2048
Inode blocks per group: 128
RAID stride: 128
RAID stripe width: 512
Flex block group size: 16
Filesystem created: Thu Jun 25 12:05:12 2015
Last mount time: Mon Aug 3 18:49:29 2015
Last write time: Mon Aug 3 18:49:29 2015
Mount count: 8
Maximum mount count: -1
Last checked: Thu Jun 25 12:05:12 2015
Check interval: 0 (<none>)
Lifetime writes: 24 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 3ea3edc4-7638-45cd-8db8-36ab3669e868
Journal backup: inode blocks
$ tune2fs -l /dev/sda1
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name: <none>
Last mounted on: /mnt/tmp
Filesystem UUID: 10df1bea-64fc-468e-8ea0-10f3a4cb9a79
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 152621056
Block count: 1220942336
Reserved block count: 61047116
Free blocks: 367343926
Free inodes: 135953194
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 732
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
Flex block group size: 16
Filesystem created: Thu Jul 23 13:54:13 2015
Last mount time: Tue Aug 4 04:35:06 2015
Last write time: Tue Aug 4 04:35:06 2015
Mount count: 3
Maximum mount count: -1
Last checked: Thu Jul 23 13:54:13 2015
Check interval: 0 (<none>)
Lifetime writes: 150 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: a266fec5-bc86-402b-9fa0-61e2ad9b5b50
Journal backup: inode blocks
sumber
Jawaban:
Bug dalam implementasi fitur ext4
dir_index
yang Anda gunakan pada sistem file tujuan Anda.Solusi: buat kembali filesytem tanpa dir_index. Atau nonaktifkan fitur menggunakan tune2fs (diperlukan kehati-hatian, lihat tautan terkait Novell SuSE 10/11: Nonaktifkan H-Tree Indexing pada sistem file ext3 yang meskipun berhubungan dengan ext3 mungkin memerlukan kehati-hatian yang serupa.
sumber
dir_index
mungkin akan mematikan kinerja akses dengan file 70m dalam satu direktori.Saran untuk pilihan yang lebih baik daripada ext4 untuk menyimpan banyak file kecil:
Jika Anda menggunakan filesystem sebagai objek toko, Anda mungkin ingin melihat menggunakan filesystem yang berspesialisasi dalam itu, mungkin dengan merugikan karakteristik lainnya. Pencarian Google cepat menemukan Ceph , yang tampaknya merupakan open source, dan dapat dipasang sebagai sistem file POSIX, tetapi juga diakses dengan API lain. Saya tidak tahu apakah itu layak digunakan pada satu host, tanpa mengambil keuntungan dari replikasi.
Sistem penyimpanan objek lain adalah OpenStack's Swift . Dokumen desainnya mengatakan menyimpan setiap objek sebagai file terpisah, dengan metadata dalam xattrs . Inilah artikel tentang itu. Mereka panduan penyebaran mengatakan mereka menemukan XFS memberikan kinerja terbaik untuk penyimpanan objek. Jadi, meskipun beban kerja bukan yang terbaik di XFS, itu tampaknya lebih baik daripada para pesaing ketika RackSpace menguji sesuatu. Kemungkinan Swift mendukung XFS karena XFS memiliki dukungan yang baik / cepat untuk atribut yang diperluas. Mungkin ext3 / ext4 akan baik-baik saja pada disk tunggal sebagai backend objek-toko jika metadata tambahan tidak diperlukan (atau jika disimpan di dalam file biner).
Swift melakukan replikasi / load-balancing untuk Anda, dan menyarankan agar Anda memberikannya filesystem yang dibuat pada disk mentah, bukan RAID . Ini menunjukkan bahwa beban kerjanya pada dasarnya terburuk untuk RAID5 (yang masuk akal jika kita berbicara tentang beban kerja dengan penulisan file kecil. XFS biasanya tidak cukup mengemasnya secara langsung, sehingga Anda tidak dapatkan tulisan full-stripe, dan RAID5 harus melakukan beberapa pembacaan untuk memperbarui parity stripe. Swift docs juga berbicara tentang penggunaan 100 partisi per drive. Saya berasumsi itu istilah Swift, dan tidak berbicara tentang membuat 100 sistem file XFS yang berbeda pada masing-masing Disk SATA.
Menjalankan XFS terpisah untuk setiap disk sebenarnya merupakan perbedaan besar . Alih-alih satu peta bebas inode raksasa , setiap disk akan memiliki XFS terpisah dengan daftar bebas terpisah. Juga, ia menghindari penalti RAID5 untuk tulisan kecil.
Jika Anda sudah memiliki perangkat lunak yang dibangun untuk menggunakan sistem file secara langsung sebagai penyimpanan objek, daripada melalui sesuatu seperti Swift untuk menangani replikasi / load-balancing, maka Anda setidaknya dapat menghindari memiliki semua file Anda dalam satu direktori. (Saya tidak melihat dokumen Swift mengatakan bagaimana mereka meletakkan file mereka ke beberapa direktori, tapi saya yakin mereka melakukannya.)
Dengan hampir semua sistem file normal, ini akan membantu untuk menggunakan struktur seperti
Mungkin sekitar 10k entri masuk akal, jadi mengambil 4 karakter yang terdistribusi dengan baik dari nama objek Anda dan menggunakannya sebagai direktori adalah solusi yang mudah. Itu tidak harus sangat seimbang. Direktori 100k aneh mungkin tidak akan menjadi masalah yang nyata, dan direktori kosong juga tidak akan ada.
XFS tidak ideal untuk banyak file kecil. Itu melakukan apa yang bisa, tetapi lebih dioptimalkan untuk streaming menulis file yang lebih besar Secara keseluruhan, ini sangat baik untuk penggunaan umum. Itu tidak memiliki
ENOSPC
tabrakan dalam pengindeksan direktori (AFAIK), dan dapat menangani memiliki satu direktori dengan jutaan entri. (Tapi masih lebih baik menggunakan setidaknya satu tingkat pohon.)Dave Chinner memiliki beberapa komentar tentang kinerja XFS dengan sejumlah besar inode yang dialokasikan , yang mengarah ke
touch
kinerja slow-ish . Menemukan inode gratis untuk dialokasikan mulai mengambil lebih banyak waktu CPU, karena bitmap inode gratis terfragmentasi. Perhatikan bahwa ini bukan masalah satu direktori besar vs banyak direktori, tetapi lebih merupakan masalah dari banyak inode yang digunakan di seluruh sistem file. Memisahkan file Anda menjadi beberapa direktori membantu dengan beberapa masalah, seperti yang membuat ext4 tersendat dalam OP, tetapi bukan masalah seluruh disk untuk melacak ruang kosong. File-sistem-per-disk Swift yang terpisah membantu dengan ini, dibandingkan dengan XFS raksasa pada RAID5.Saya tidak tahu apakah btrf bagus dalam hal ini, tapi saya pikir itu mungkin. Saya pikir Facebook mempekerjakan pengembang utamanya karena suatu alasan. : P Beberapa tolok ukur yang saya lihat, tentang hal-hal seperti menghapus sumber kernel Linux, menunjukkan btrfs baik.
Saya tahu reiserfs dioptimalkan untuk kasus ini, tetapi hampir tidak, jika sama sekali, dipertahankan lagi. Saya benar-benar tidak bisa merekomendasikan pergi dengan reiser4. Mungkin menarik untuk bereksperimen. Tapi ini adalah pilihan yang paling tidak tahan di masa depan. Saya juga melihat laporan penurunan kinerja pada reiserFS tua, dan tidak ada alat defrag yang bagus. (google
filesystem millions of small files
, dan lihat beberapa jawaban stackexchange yang ada.)Saya mungkin melewatkan sesuatu, jadi rekomendasi terakhir: tanyakan tentang ini di serverfault! Jika saya harus memilih sesuatu sekarang, saya akan mengatakan mencoba BTRFS, tetapi pastikan Anda memiliki cadangan. (khususnya jika Anda menggunakan BTRFS's built-in multiple disk redundancy, alih-alih menjalankannya di atas RAID. Keunggulan kinerja bisa jadi besar, karena file kecil adalah berita buruk untuk RAID5, kecuali itu adalah beban kerja yang sebagian besar dibaca.)
sumber
/
. Semoga itu tidak mempengaruhi terlalu banyak tempat dalam kode Anda. (Anda harus memastikan direktori dibuat, jika membuat file baru gagal denganENOENT
). Tanyakan pada serverfault apakah ada sistem file lain.Untuk masalah ini di bawah ini adalah apa yang saya lakukan untuk memperbaikinya (Anda mungkin perlu akses sudo untuk langkah-langkah di bawah ini):
Ruang Inode yang digunakan adalah 100% yang dapat diambil menggunakan perintah di bawah ini
df -i /
Coba cari tahu apakah ini masalah inode dengan:
Cobalah untuk menemukan folder root dengan jumlah inode yang besar:
Cobalah untuk menemukan folder tertentu:
sumber