“Cihazda yer kalmaması” için başka bir neden var mı?

Harici bir usb 3.0 sürücüye bir hd yedeklemek için bir Ubuntu sunucu sisteminde Dirvish kullanıyorum. Birkaç gün öncesine kadar her şey yolunda gitti, ancak şimdi her yedekleme "cihazda (28) boş alan yok" ve "dosya sistemi dolu" olarak başarısız oluyor. Ne yazık ki bu kadar basit değil: Cihazda 500 GB'den fazla boş alan var.

Detaylar:

rsync_error:

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

günlük, isabet edene kadar her zamanki gibi görünür:

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

Ancak, yukarıda belirtildiği gibi, cihazda çok fazla alan var:

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

ve ayrıca çok sayıda inode kaldı:

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

Cihaz rw olarak monte edilmiştir:

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

İşlem kök olarak çalışıyor.

Hiçbir şeyi değiştirmediğimi söylemek üzereydim ama bu doğru değil: Yedeklediğim sürücü için acl'yi açtım:

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

Sorun bu olabilir mi? Evet ise, nasıl? root dosyalara hala tam erişime sahiptir.

DÜZENLE:

Sadece geçici dizinleri kontrol ettim:

• / tmp yalnızca boş bir .webmin klasörü içerir
• / var / tmp boş

bu dizinlerin bulunduğu dosya sisteminde çok fazla boş alan ve inode vardır:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2:

Dizinler oldukça büyük, ancak> 2 GB değil. Yedeklemenin başarısız olduğu en büyük dosyalardan biri bile değil, 7530 dosya içeriyor.

EDIT3:

Bu soruyu gönderirken alakalı olmadığını düşündüğüm bir bilgi:

Yedeklemelerin başarısızlığa başlamasından bir gün önce yedeklenmiş dosya sistemlerinde acls etkinleştirdim. Şimdi bu Dirvish (veya rsync) tüm dosyaları değişti düşünmeye tetikledi varsayalım böylece sabit bağlantılı yerine kopyalanacak dosyaların listesi çok büyüktü. Bu muhtemelen bazı tamponların çok küçük olduğu anlamına gelebilir.

Bugün boş bir diske tam yedekleme kusursuz çalıştı. Bundan sonra artımlı bir yedeklemeyi deneyeceğim. Bu sorunun nedeninin aktive etmenin etkinleştirilip etkinleştirilmediğini gösterecektir.

Benim şüphem (bakınız EDIT3) haklıydı: Dosya sistemine acl desteği eklemek rsync / dirvish tüm dosyaların değiştiğini düşündürdü. Bu nedenle, artımlı bir yedekleme yapmak ve sadece mevcut dosyalara sabit bağlantılar oluşturmak yerine, sabit disk bunun için yeterli alana sahip olmadığı için başarısız olan tam bir yedekleme oluşturmaya çalıştı.

Hata mesajı aslında doğruydu.

Boş bir yedek diskle yeniden başladıktan sonra, artımlı yedeklemeler önceki gibi çalıştı.

Kalan düğümlerin% 2'sine baktığımda, EXT dosya sisteminin uyguladığı kök rezervleri hakkında düşündürdüm. Bunlara göz atmak isteyebilirsiniz:

1. " Bir dosya sisteminde kök için ayrılan yer - neden? "
2. " Dosya sistemi saklıdır bloklar için makul boyutu‘’non-OS diskler için? "

Bazı eski yedeklerin kullanımda olan düğüm sayısını azaltacağını umarak .tar.gz'yi denerdim.

Ben dummzeuch sorununa bir çözüm bulmak görüyorum ama aslında disk yeterli inodes / boş alan olabilir ve hala belirli dizinleri aktarmaya çalışırken "cihazda boş yer" gösteren nerede buldum bir durum daha var.

Bunun nedeni, dizin dizinlemenin de etkinleştirildiği ext4 dosya sistemiyle biçimlendirilmiş blok aygıtlarındaki karma çakışmalardan kaynaklanır, özellikle tek bir dizin içinde 100k'dan fazla dosya barındırıyorsa ve dosyaların adı aynı algoritmadan (önbellek dosyaları, md5sum dosya adları vb.) .)

Çözüm başka bir dizin indeksleme algoritmasıyla denemektir:

tune2fs -E "hash_alg=tea" /dev/blockdev_name

veya bu engelleme aygıtı için tamamen dizin dizine eklemeyi devre dışı bırakmak (performans zarar görebilir)

tune2fs -O ^dir_index /dev/blockdev_name

Başka bir çözüm, dizinin bu tür dosyalarla ne doldurduğunu görmek ve yazılımı düzeltmektir.

Olası çözüm, içinde büyük miktarda dosya bulunan klasörün içeriğini birden fazla ayrı alt klasöre bölmektir.

Sorunun tam açıklaması Axel Wagner tarafından burada sunulmaktadır

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

Şerefe.

Dizinin kendisinde 2 GB boyut sınırı vardır - yani dizin boyutu> 2 GB olan çok fazla dosyanız varsa (dizindeki dosyaların boyutu DEĞİL), bir sorun yaşarsınız. Söyledikten sonra, sadece 2,8 M inot kullanıldığında, bu bir sorun olmamalıdır. Genellikle yaklaşık 15M inode olur.

Yani bu çok yardımcı olmayabilir - ancak yedekleme cihazınızda ext4'ü deneyin?

Sysctl'de Inotify izleyici sınırınızı artırın:

fs.inotify.max_user_watches = 100000 

Ve yeniden başlatın veya bunun sysctl -wsürümünü de yapın.

Genellikle bunu yapar. Bir şeyin çekirdeğinde çok fazla açık dosyası var ve hata tamamen yanıltıcı. Dropbox bunun klasik bir örneğidir.

Birkaç başka şeyi kontrol etmenizi öneririm:

1. Geçici direktörünüzün dolup dolmadığına bakın. Bazen ara depolama için kullanılır ve kolayca dolar.
2. Silinmiş bir dosyaya hala açıklayıcı tutan bir işlem olup olmadığını kontrol edin. Df uygun büyüklükte rapor ettiğinden şans daha azdır, ancak yine de zarar görmez.

Sorunuma bir çözüm ararken bu konuyu yeni buldum.

Gerçekten de ENOSPC'nin en azından başka bir nedeni var. Ve bir ZFS dosya sisteminden bir EXT4 olana kopyalarken de rsync ile sahtekarlık yapıyorum:

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

Bu durumda:

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr açıklıyor:

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

Benim durumumda, tüm dosya sistemini yeniden biçimlendirmem gerekiyor. :-(