Bagaimana cara memperbaiki kesalahan “Tidak ada ruang yang tersisa di perangkat” selama mv saat perangkat memiliki banyak ruang?

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

— Chris.Caldwell
sumber

Apakah file-file tersebut di-coped ke banyak direktori, atau Anda mencoba menulis file 1,5 juta ke direktori target tunggal?

— snoopy

bukan 1,5m, 15m, dan ya, semua ke direktori yang sama. Sebenarnya sudah ada lebih dari 40m di sana, dan sekitar 30m lebih untuk total.

— Chris.Caldwell

Oh, lihat, troll downvote acak menyerang lagi. Saya kira Anda tidak mau menyebutkan MENGAPA Anda downvote?

— Chris.Caldwell

Suara turun mungkin karena pertanyaan Anda lebih cocok untuk Unix.stackexchange atau askubuntu karena tidak terkait pemrograman. Jika tidak ada bahasa pemrograman di tag Anda, kemungkinan akan mendapatkan suara turun.

— technosaurus

@ Chris - tampaknya mirip dengan masalah ini di SF: serverfault.com/questions/384541/…

— snoopy

Jawaban:

Bug dalam implementasi fitur ext4 dir_indexyang 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.

(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)

ext4: Misterius “Tidak ada ruang yang tersisa di perangkat” - kesalahan

ext4 memiliki fitur yang disebut dir_index diaktifkan secara default, yang cukup rentan terhadap benturan hash.

......

ext4 memiliki kemungkinan untuk hash nama file isinya. Ini meningkatkan kinerja, tetapi memiliki masalah "kecil": ext4 tidak menumbuhkan hashtable-nya, ketika mulai mengisi. Alih-alih mengembalikan -ENOSPC atau "tidak ada ruang yang tersisa di perangkat".

— steve
sumber

oh sial, itu terdengar persis seperti itu, dan seperti rasa sakit total untuk memperbaikinya. Sekitar sebulan untuk menyalin. dapatkah ini dilakukan tanpa kehilangan isinya? Saya harus meneliti dir_index dll besok. Wow, tidak akan pernah terpikirkan tentang itu.

— Chris.Caldwell

Menambahkan perintah tune2fs untuk menonaktifkan indeks, jika Anda ingin mencobanya.

— steve

@Steve terlihat dengan baik. Sayangnya mematikan dir_indexmungkin akan mematikan kinerja akses dengan file 70m dalam satu direktori.

— mjturner

Ya. Saya tidak memerlukan kinerja puncak, tetapi pencarian untuk setiap file akan mengerikan. Jadi sekarang saya melihat xfs atau array 10k atau lebih subfolder. Subfolder adalah solusi yang masuk akal, namun dengan ext4 saya masih menghadapi risiko tabrakan. apakah xfs menderita masalah yang sama? Saya membacanya menggunakan pohon B +, tapi itu tidak berarti banyak bagi saya sejauh memastikan tidak pernah ada tabrakan. Ada dunia informasi yang salah di luar sana, dan saya pernah mendengar klaim bahwa ia memperlambat lebih dari satu juta file, dan mengklaim bahwa itu tidak.

— Chris.Caldwell

Saya pikir ini adalah jawaban yang bagus, dan saya ingin menandainya, tapi saya pikir akan lebih baik jika kita bisa memperbaiki, bukan hanya diagnosis. Adakah yang tahu kalau xfs menderita hal seperti ini? Saya sudah membaca ulasan campuran bahwa itu timbangan baik-baik saja, atau tidak lebih dari 1m.

— Chris.Caldwell

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

1234/5678   # nested medium-size directories instead of
./12345678   # one giant directory

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 ENOSPCtabrakan 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 touchkinerja 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.)

— Peter Cordes
sumber

Terima kasih banyak. Saya telah melihat banyak orang menggunakan sub-folder, dan pada kenyataannya bertahun-tahun yang lalu saya memiliki jenis solusi pada pengaturan yang berbeda, tetapi lapisan lain yang saya harap akan dihindari. Sepertinya overhead dari melakukannya dengan cara itu, bagaimanapun, akan jauh lebih sedikit daripada menemukan fs yang hanya berfungsi untuk tujuan ini. RE: XFS, ini mengejutkan karena sangat buruk pada jumlah file yang tinggi karena jawaban yang sering diberikan. BTRFS, wiki: "entri direktori muncul sebagai item direktori, yang nilai kunci kanannya adalah hash CRC32C dari nama file mereka". Bukankah itu masalah yang sama yang kita miliki?

— Chris.Caldwell

@ Chris.Caldwell: Anda harus memeriksa, tetapi saya berasumsi BTRFS menangani tabrakan hash dengan mendukung beberapa entri dalam ember hash yang sama, daripada ENOSPC. Pernahkah Anda berpikir untuk hanya menyimpan barang-barang Anda di database, daripada memisahkan file dalam sistem file? Saya belum pernah membangun sistem untuk menangani data semacam ini. Saya menggunakan XFS, yang sangat bagus untuk apa saya menggunakannya (menyimpan video, dan keperluan umum kode sumber Unix dan lainnya.)

— Peter Cordes

Cara sistem file dirancang, tingkat direktori lebih murah. Dua pencarian cepat dalam tabel kecil akan lebih cepat dari satu pencarian lambat di tabel melimpah yang menyimpan lebih banyak data daripada yang dioptimalkan untuk. Seperti yang saya katakan, Anda tidak harus mendistribusikan file dengan sempurna di antara direktori, jadi Anda bisa mengambil 4 karakter pertama dari nama file Anda, dan menyisipkan a /. Semoga itu tidak mempengaruhi terlalu banyak tempat dalam kode Anda. (Anda harus memastikan direktori dibuat, jika membuat file baru gagal dengan ENOENT). Tanyakan pada serverfault apakah ada sistem file lain.

— Peter Cordes

@ Chris.Caldwell: Saya harus benar-benar menyalin jawaban ini ke pertanyaan yang relevan. Ada beberapa yang sudah ada. Saya ingin tahu apa yang "seharusnya" digunakan untuk penyimpanan objek, dan menemukan beberapa dokumen tentang Swift. Rupanya ia menyimpan objek sebagai file terpisah pada XFS (tetapi dengan XFS terpisah untuk setiap disk, bukan RAID. Ia menangani redundansi itu sendiri).

— Peter Cordes

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 /

Inode Filesystem IUsed IFree IUse% Dipasang di

/dev/xvda1            524288   524288  o     100% /

Perlu membebaskan iNoted, maka perlu mencari file yang ada di sini jumlah i node menggunakan perintah di bawah ini:

Coba cari tahu apakah ini masalah inode dengan:

df -ih

Cobalah untuk menemukan folder root dengan jumlah inode yang besar:

for i in /*; do echo $i; find $i |wc -l; done

Cobalah untuk menemukan folder tertentu:

for i in /src/*; do echo $i; find $i |wc -l; done

sekarang kita telah memusatkan perhatian ke folder dengan sejumlah besar file di dalamnya. Jalankan perintah di bawah ini satu demi satu untuk menghindari kesalahan (Dalam kasus saya folder sebenarnya adalah / var / spool / clientmqueue):

find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +

— Barani r
sumber