Cihaz çok fazla alana sahip olduğunda, mv sırasında intermittan “Cihazda yer kalmadı” hatalarını nasıl düzeltebilirim?

• Masaüstünde Ubuntu 14.04
• Kaynak Sürücü: / dev / sda1: 5TB ext4 tek
  sürücü hacmi
• Hedef Hacim: / dev / mapper / arşiv-değişken: raid6 (mdadm) lvm
  bölümü ve ext4 ile 18 TB hacim

Taşınacak yaklaşık 15 milyon dosya var ve bazıları kopya olabilir (kopyaların üzerine yazmak istemiyorum).

Kullanılan komut (kaynak dizinden):

ls -U |xargs -i -t mv -n {} /mnt/archive/targetDir/{}

Beklendiği gibi bu birkaç gün devam ediyor, ancak artan sıklıkta hata alıyorum. Çalıştığında, hedef sürücü yaklaşık% 70 doluydu, şimdi yaklaşık% 90 idi. Bu hamlelerin yaklaşık 1 / 200'ünü gösteriyordu, şimdi ise 1 / 5'i gösteriyordu ve yanılıyordu. Dosyaların hiçbiri 100 MB'ın üzerinde değil, çoğu 100 bin dolar civarında.

Bazı bilgiler:

$ 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

İşte çıkışım:

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

Bu hataya yapılan ilanları LOTS buldum, ancak prognoz uymuyor. "Sürücünüz gerçekten dolu" veya "inode bitirdiniz" veya hatta "önyükleme biriminiz dolu" gibi sorunlar. Çoğunlukla, 3. parti yazılımlarla uğraşırlar ve dosyaları nasıl kullandıklarından dolayı bir soruna neden olurlar ve hepsi sabittir, yani HERHANGİ hamle başarısız olur.

Teşekkürler.

EDIT: burada bir örnek başarısız ve başarılı bir dosya:

FAILED (hala kaynak sürücüde)

ls -lhs 702637545.pdf
16K -rw-rw-r-- 1 myUser myUser 16K Jul 24 20:52 702637545.pdf

SUCCEEDED (Hedef hacimde)

ls -lhs /mnt/archive/targetDir/704886680.pdf
104K -rw-rw-r-- 1 myUser myUser 103K Jul 25 01:22 /mnt/archive/targetDir/704886680.pdf

Ayrıca, tüm dosyalar başarısız olmasa da, başarısız olan bir dosya HER ZAMAN başarısız olur. Tekrar tekrar denersem tutarlı olur.

EDIT: @mjturner tarafından istek başına bazı ek komutlar

$ 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

dir_indexHedef dosya sisteminizde kullanmakta olduğunuz ext4 özelliğinin uygulanmasında hata .

Çözüm: dir_index olmadan filesytem'i yeniden oluşturun. Ya da devre dışı bırakma özelliği bazı dikkatli ilgili bağlantı bkz gerekli (tune2fs kullanılarak bir ext3 devre dışı bırakma 'H-ağaç indeksleme Novell SuSE'yi 10/11 ile ilgilidir, ancak ext3'te benzer dikkat gerektirir.

(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: Gizemli "Aygıtta yer kalmadı" -errors

ext4, varsayılan olarak etkinleştirilmiş, karma çarpışmalara oldukça duyarlı olan dir_index adlı bir özelliğe sahiptir.

......

ext4, içeriğinin dosya adlarını sağlama olanağına sahiptir. Bu performansı arttırır, ancak “küçük” bir problemi vardır: ext4 doldurmaya başladığında hashtable'ını büyütmez. Bunun yerine -ENOSPC veya “cihazda yer kalmadı” döndürür.

Küçük dosya yığınlarını depolamak için ext4'ten daha iyi seçenekler için öneriler:

Dosya sistemini bir nesne deposu olarak kullanıyorsanız, bu konuda uzmanlaşmış, muhtemelen diğer özelliklerin zararına yönelik bir dosya sistemi kullanmak isteyebilirsiniz. Hızlı bir Google arama bulundu Ceph açık kaynak olarak görünmektedir ve POSIX dizin olarak monte edilebilir, aynı zamanda diğer API'larla erişilen. Çoğaltmadan yararlanmadan tek bir ana bilgisayarda kullanmaya değip değmeyeceğini bilmiyorum.

Başka bir nesne depolama sistemi OpenStack'in Swift'idir . Tasarım dokümanları, her nesneyi xattrs'de meta verilerle ayrı bir dosya olarak sakladığını söylüyor . İşte bu konuda bir makale. Onların dağıtım kılavuzu onlar XFS nesne depolama için en iyi performansı verdi bulduğunu söylüyor. Dolayısıyla, iş yükü XFS'nin en iyi olduğu şey olmasa da, RackSpace bir şeyleri test ederken rakiplerden daha iyi göründü. Muhtemelen Swift, XFS'yi tercih eder çünkü XFS, genişletilmiş özellikler için iyi / hızlı desteğe sahiptir. Ext3 / ext4'ün, fazladan meta verilere ihtiyaç duyulmaması durumunda (ya da ikili dosyanın içinde tutulması halinde), nesne deposu arkası olarak tek disklerde tamam olacağı söylenebilir.

Swift, çoğaltma / yük dengeleme işlemini sizin için yapar ve RAID değil , ham disklerde yapılan dosya sistemlerini vermenizi önerir . İş yükünün RAID5 için en kötü durum olduğuna dikkat çekiyor (bu, küçük dosyaların yazdığı bir iş yükünden bahsediyorsak mantıklı geliyor. XFS genellikle bunları tam anlamıyla paketlemiyor, bu nedenle tam şerit yazmaları olsun ve RAID5'in parite şeritini güncellemek için bazı okumalar yapması gerekiyor.Türev dokümanlar ayrıca sürücü başına 100 bölüm kullanma hakkında da konuşuyorlar. SATA diski.

Her disk için ayrı bir XFS çalıştırmak aslında büyük bir farktır . Bir dev serbest serbest inode haritasının yerine, her diskin ayrı boş listeleri olan ayrı bir XFS'si olacaktır. Ayrıca, küçük yazmalar için RAID5 cezasını da önler.

Yazılımınızı, çoğaltma / yük dengelemeyi işlemek için Swift gibi bir şeyden geçmek yerine, doğrudan bir nesne deposu olarak bir dosya sistemini kullanmak üzere oluşturmuşsanız, en azından tüm dosyalarınızı tek bir dizinde bulundurmaktan kaçınabilirsiniz. (Swift belgelerinin, dosyalarını nasıl birden fazla klasöre yerleştirdiklerini söylediklerini görmedim, fakat kesinlikle eminim.)

Neredeyse tüm normal dosya sistemlerinde, bu gibi bir yapı kullanmaya yardımcı olacaktır.

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

Muhtemelen yaklaşık 10k giriş makul, bu nedenle nesne adınızın iyi dağıtılmış 4 karakterini almak ve bunları dizin olarak kullanmak kolay bir çözümdür. Çok iyi dengelenmesi gerekmiyor. Tek 100k dizini muhtemelen göze çarpan bir sorun olmayacak ve bazı boş dizinler de olmayacak.

XFS , büyük boyutlu küçük dosyalar için ideal değildir. Elinden geleni yapar, ancak daha büyük dosyaların akışını yazmak için daha optimize edilmiştir. Yine de genel kullanım için çok iyi. ENOSPCDizin dizininde (AFAIK) çarpışmalar bulunmuyor ve milyonlarca giriş içeren bir dizine sahip olabilir. (Ama en az bir seviye ağaç kullanmak hala daha iyi.)

Dave Chinner , çok sayıda inode atanmış XFS performansı hakkında bazı yorumlarda bulundu ve bu durum yavaş touchperformansa neden oldu. Tahsis edilecek bir serbest inode bulmak serbest inode bitmap parçalandığı için daha fazla CPU zamanı harcar. Bunun birden fazla dizine karşı büyük bir dizin olmadığına değil, tüm dosya sistemi üzerinde kullanılan pek çok inode sorunu olduğuna dikkat edin. Dosyalarınızı birden fazla dizine bölmek, OP4'te boğulan ext4 gibi bazı sorunlara yardımcı olur, ancak boş alanı izlemenin tüm disk sorunu değildir. Swift'in disk başına ayrı bir dosya sistemi, RAID5'teki dev XFS'ye kıyasla bu konuda yardımcı olur.

Btrfs bu konuda iyi mi, bilmiyorum ama bence olabilir. Bence Facebook lider geliştiricisini bir sebepten kullanıyor. : P Linux çekirdeği kaynağını kaldırmak gibi şeylerin bazı karşılaştırmaları btrfs'in iyi yaptığını gösteriyor.

Reiserfs’in bu durum için optimize edildiğini biliyorum , ancak artık hiç de korunmuyor. Reiser4 ile gitmeyi gerçekten tavsiye edemiyorum. Yine de deney yapmak ilginç olabilir. Ancak bu, geleceğe dönük en az seçenek. Ayrıca yaşlı reiserFS'de performans düşüşü raporları gördüm ve iyi bir birleştirme aracı yok. (google filesystem millions of small filesve mevcut stackexchange cevaplarından bazılarına bakın.)

Muhtemelen bir şey eksik, bu yüzden son öneri: Bu konuda serverfault sor! Şu an bir şey seçmek zorunda olsaydım, BTRFS'ye bir şans verin derdim ama yedekleriniz olduğundan emin olun. (özellikle BTRFS'nin yerleşik çoklu disk yedeklemesi kullanıyorsanız, RAID'in üzerinde çalıştırmak yerine, küçük boyutlu dosyalar çoğunlukla RAID5 için kötü bir haber olduğundan, çoğunlukla okuma iş yükü olmadıkça, performans avantajları büyük olabilir.)

Aşağıdaki bu sorun için düzeltmek istediğim şeydi (aşağıdaki adımlar için sudo erişimine ihtiyacınız olabilir):

1. Inode'un kullanılan alanı% 100 idi ve bu komut aşağıdaki komutu kullanarak alınabildi

   df -i /

Dosya Sistemi İnodes IUsed IFree IUse% Monte edilmiş

/dev/xvda1            524288   524288  o     100% /

2. İNoted'i serbest bırakmanız gerekir, bu nedenle aşağıdaki komutu kullanan i düğümü sayısı olan dosyaları bulmanız gerekir:

Bunun bir inodes sorunu olup olmadığını bulmaya çalışın:

df -ih

Büyük düğüm sayısı olan kök klasörleri bulmaya çalışın:

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

Belirli klasörleri bulmaya çalışın:

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

3. şimdi içinde çok sayıda dosya bulunan klasöre sıfırladık. Herhangi bir hatayı önlemek için aşağıdaki komutları arka arkaya çalıştırın (Benim durumumda asıl klasör / var / spool / clientmqueue idi):

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 {} +