Czy jest jakiś inny powód „braku miejsca na urządzeniu”?

Korzystam z Dirvish na serwerze z systemem Ubuntu do tworzenia kopii zapasowych dysku twardego na zewnętrznym dysku USB 3.0. Jeszcze kilka dni temu wszystko działało dobrze, ale teraz każda kopia zapasowa kończy się niepowodzeniem z „brakiem miejsca na urządzeniu (28)” i „zapełnieniem systemu plików”. Niestety nie jest to takie proste: na urządzeniu jest> 500 GB wolnego miejsca.

Detale:

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]

dziennik wygląda prawie jak zwykle, dopóki nie trafi:

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

Ale, jak powiedziano powyżej, na urządzeniu jest dużo miejsca:

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

a także pozostało wiele i-węzłów:

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

Urządzenie jest montowane jako rw:

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

Proces działa jako root.

Już miałem powiedzieć, że nic nie zmieniłem, ale to nie do końca prawda: włączyłem acl dla dysku, którego kopię zapasową wykonuję:

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

Czy to może być problem? Jeśli tak to jak? root nadal ma pełny dostęp do plików.

EDYTOWAĆ:

Właśnie sprawdziłem katalogi tymczasowe:

• / tmp zawiera tylko pusty folder .webmin
• / var / tmp jest pusty

system plików, w którym znajdują się te katalogi, ma dużo wolnego miejsca i i-węzłów:

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% /

EDYCJA 2:

Katalogi są dość duże, ale nie> 2 GB. Ten, w którym tworzenie kopii zapasowej kończy się niepowodzeniem, nie jest nawet jednym z największych, zawiera 7530 plików.

EDYCJA 3:

Jedna informacja, której nie uznałem za istotną, publikując to pytanie:

Dzień przed tym, jak kopie zapasowe zaczęły się nie powieść, aktywowałem acls w systemach plików, których kopie zapasowe utworzono. Zakładam teraz, że to spowodowało, że Dirvish (lub rsync) pomyślał, że wszystkie pliki się zmieniły, więc lista plików, które miały zostać skopiowane, a nie na stałe połączone, była bardzo duża. Może to oznaczać, że niektóre bufory były zbyt małe.

Dzisiaj pełna kopia zapasowa na pustym dysku działała bezbłędnie. Następnie spróbuję wykonać przyrostową kopię zapasową. To pokaże, czy aktywacja acls była przyczyną problemu.

Moje podejrzenie (patrz EDIT3) najwyraźniej miało rację: dodanie obsługi acl do systemu plików sprawiło, że rsync / dirvish uznał, że wszystkie pliki się zmieniły. Zamiast tworzyć przyrostową kopię zapasową i tworzyć twarde łącza do już istniejących plików, próbował utworzyć pełną kopię zapasową, która oczywiście nie powiodła się, ponieważ na dysku twardym nie było wystarczającej ilości miejsca.

Tak więc komunikat o błędzie był właściwie poprawny.

Po ponownym uruchomieniu z pustym dyskiem kopii zapasowej przyrostowe kopie zapasowe działały jak poprzednio.

Patrząc na 2% pozostałych i-węzłów, pomyślałem o rezerwach głównych narzuconych przez system plików EXT. Możesz to sprawdzić:

1. „ Zarezerwowane miejsce dla roota w systemie plików - dlaczego? ”
2. „ Rozsądny rozmiar„ bloków zarezerwowanych dla systemu plików ”dla dysków innych niż system operacyjny? ”

Spróbowałbym .tar.gz niektórych starszych kopii zapasowych, mając nadzieję, że zmniejszy to liczbę używanych i-węzłów.

Widzę, że dummzeuch znajduje rozwiązanie swojego problemu, ale w rzeczywistości znalazłem jeszcze jeden przypadek, w którym dysk może mieć wystarczająco dużo i-węzłów / wolnego miejsca i nadal pokazuje „brak miejsca na urządzeniu” podczas próby przeniesienia niektórych katalogów.

Jest to spowodowane kolizjami skrótu na urządzeniach blokowych sformatowanych przy użyciu systemu plików ext4, w którym indeksowanie katalogów jest również włączone, szczególnie tam, gdzie w jednym katalogu znajduje się ponad 100 000 plików, a nazwy plików są generowane na podstawie tego samego algorytmu (pliki pamięci podręcznej, nazwy plików md5sum itp. .)

Rozwiązaniem jest wypróbowanie innego algorytmu indeksowania katalogów:

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

lub całkowicie wyłączyć indeksowanie katalogów dla tego urządzenia blokowego (może zaszkodzić wydajności)

tune2fs -O ^dir_index /dev/blockdev_name

Innym rozwiązaniem jest sprawdzenie, co wypełnia katalog takimi plikami i naprawa oprogramowania.

Możliwym rozwiązaniem jest podzielona zawartość folderu z dużą ilością plików w wielu osobnych podfolderach.

Pełny opis problemu zaprezentował Axel Wagner tutaj

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

Twoje zdrowie.

Sam katalog ma limit rozmiaru 2 GB - tzn. Jeśli masz tyle plików, że rozmiar katalogu wynosi> 2 GB (NIE rozmiar plików w katalogu), będziesz mieć problem. To powiedziawszy, przy użyciu jedynie i-węzłów 2,8 mln, nie powinno to stanowić problemu. Zwykle zdarza się około 15 milionów i-węzłów.

Może to nie być zbyt pomocne - ale spróbuj ext4 na urządzeniu do tworzenia kopii zapasowych?

Zwiększ limit obserwatorów Inotify w sysctl:

fs.inotify.max_user_watches = 100000 

Uruchom ponownie komputer lub wykonaj jego sysctl -wwersję.

Zwykle to zrobi. Coś ma zbyt wiele otwartych plików w jądrze, a błąd jest całkowicie mylący. Dropbox jest tego klasycznym przykładem.

Sugerowałbym, aby sprawdzić kilka innych rzeczy:

1. Sprawdź, czy Twój tymczasowy katalog się nie zapełnia. Czasami służy do przechowywania pośredniego i łatwo się zapełnia.
2. Sprawdź, czy istnieje proces, który nadal trzyma deskryptor usuniętego pliku. Szanse są mniej prawdopodobne, ponieważ df zgłasza odpowiedni rozmiar, ale nadal nie będzie bolało.

Właśnie znalazłem ten temat, szukając rozwiązania mojego problemu.

Rzeczywiście istnieje co najmniej z innego powodu ENOSPC. I też go polecam przy użyciu rsync podczas kopiowania z systemu plików ZFS do systemu EXT4:

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

W tym przypadku:

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

man 7 xattr wyjaśnia:

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

W moim przypadku oznacza to, że muszę sformatować cały system plików. :-(