Jak naprawić przejściowe błędy „Brak miejsca na urządzeniu” podczas mv, gdy urządzenie ma dużo miejsca?

• Ubuntu 14.04 na pulpicie
• Napęd źródłowy: / dev / sda1:
  wolumin pojedynczego napędu 5 TB ext4
• Docelowa objętość: / dev / mapper / archive-lvarchive: wolumin 18 TB (RAID6) z partycją lvm
  i ext4

Do przeniesienia jest około 15 milionów plików, a niektóre mogą być duplikatami (nie chcę zastępować duplikatów).

Użyto polecenia (z katalogu źródłowego):

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

Trwało to od kilku dni, jak oczekiwano, ale pojawia się błąd w zwiększaniu częstotliwości. Kiedy się uruchomił, dysk docelowy był zapełniony w około 70%, teraz wynosi około 90%. Kiedyś było to około 1/200 ruchów, które wskazywałyby na błędy i błędy, teraz jest to około 1/5. Żaden z plików nie przekracza 100 Mb, większość ma około 100 KB

Niektóre informacje:

$ 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

Oto moje wyniki:

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

Znalazłem DUŻO wpisów dotyczących tego błędu, ale prognozy nie pasują. Takie problemy, jak „Twój dysk jest naprawdę pełny”, „Skończyły ci się i-węzły”, a nawet „Twój wolumin / boot jest pełny”. Przeważnie jednak mają do czynienia z oprogramowaniem innych firm powodującym problem z powodu sposobu, w jaki obsługuje pliki, i wszystkie są stałe, co oznacza, że ​​KAŻDY ruch się nie powiedzie.

Dzięki.

EDYCJA: tutaj jest próbka pliku nieudanego i udanego:

FAILED (wciąż na dysku źródłowym)

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

SUCCEEDED (w przypadku głośności docelowej)

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

Ponadto, chociaż nie wszystkie pliki zawodzą, plik, który zawodzi, ZAWSZE zawodzi. Jeśli spróbuję to raz za razem, będzie to zgodne.

EDYCJA: Niektóre dodatkowe polecenia na żądanie @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

Błąd w implementacji funkcji ext4, dir_indexktórej używasz w docelowym systemie plików.

Rozwiązanie: ponownie utworzyć system plików bez dir_index. Lub wyłącz funkcję za pomocą tune2fs (wymagana ostrożność, patrz odnośnik link Novell SuSE 10/11: Wyłącz indeksowanie H-drzewa w systemie plików ext3, który chociaż wiąże się z ext3, może wymagać podobnej ostrożności.

(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: Tajemnicze błędy „Brak miejsca na urządzeniu”

ext4 ma domyślnie włączoną funkcję dir_index, która jest dość podatna na kolizje mieszające.

......

ext4 ma możliwość mieszania nazw plików z zawartością. Zwiększa to wydajność, ale ma „mały” problem: ext4 nie powiększa swojego hashtable, gdy zaczyna się zapełniać. Zamiast tego zwraca wartość -ENOSPC lub „brak miejsca na urządzeniu”.

Sugestie dotyczące wyborów lepszych niż ext4 do przechowywania mas małych plików:

Jeśli używasz systemu plików jako magazynu obiektów, możesz rozważyć użycie systemu plików, który się w nim specjalizuje, być może ze szkodą dla innych cech. Szybkie wyszukiwanie w Google znalazło Ceph , który wydaje się być open source, i można go zamontować jako system plików POSIX, ale można go również uzyskać za pomocą innych interfejsów API. Nie wiem, czy warto korzystać z jednego hosta bez korzystania z replikacji.

Kolejnym systemem przechowywania obiektów jest Swift firmy OpenStack . Dokumenty projektowe mówią, że przechowuje każdy obiekt jako osobny plik z metadanymi w xattrs . Oto artykuł na ten temat. Ich przewodnik wdrażania mówi, że odkryli, że XFS zapewnia najlepszą wydajność przechowywania obiektów. Więc chociaż obciążenie nie jest tym, w czym XFS jest najlepszy, było najwyraźniej lepsze niż konkurencja, gdy RackSpace testował różne rzeczy. Prawdopodobnie Swift faworyzuje XFS, ponieważ XFS ma dobre / szybkie wsparcie dla rozszerzonych atrybutów. Może się zdarzyć, że ext3 / ext4 działałby dobrze na pojedynczych dyskach jako backend przechowalni obiektów, gdyby dodatkowe metadane nie były potrzebne (lub byłyby przechowywane w pliku binarnym).

Swift wykonuje dla ciebie replikację / równoważenie obciążenia i sugeruje, abyś dał jej systemy plików wykonane na dyskach surowych, a nie RAID . Wskazuje, że jego obciążenie pracą jest zasadniczo najgorszym przypadkiem dla RAID5 (co ma sens, jeśli mówimy o obciążeniu pracą z zapisem małych plików. XFS zazwyczaj nie pakuje ich od razu do głowy, więc nie dostajemy zapisy z pełnym paskiem, a RAID5 musi dokonać pewnych odczytów, aby zaktualizować pasek parzystości. Dokumenty Swift mówią również o używaniu 100 partycji na dysk. Zakładam, że jest to termin Swift i nie mówię o tworzeniu 100 różnych systemów plików XFS na każdym Dysk SATA.

Uruchamianie osobnego XFS dla każdego dysku to tak naprawdę ogromna różnica . Zamiast jednej gigantycznej mapy wolnych i-węzłów każdy dysk będzie miał osobny XFS z osobnymi wolnymi listami. Ponadto pozwala uniknąć kary RAID5 za małe zapisy.

Jeśli masz już utworzone oprogramowanie do korzystania z systemu plików bezpośrednio jako magazynu obiektów, zamiast przechodzenia przez coś takiego jak Swift do obsługi replikacji / równoważenia obciążenia, możesz przynajmniej uniknąć posiadania wszystkich plików w jednym katalogu. (Nie widziałem, żeby doktorzy Swift mówili, jak rozkładają swoje pliki na wiele katalogów, ale jestem pewien, że tak.)

W prawie każdym normalnym systemie plików pomoże to w użyciu takiej struktury

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

Prawdopodobnie około 10 000 wpisów jest rozsądne, więc pobranie dobrze rozłożonych 4 znaków nazw obiektów i użycie ich jako katalogów jest łatwym rozwiązaniem. To nie musi być bardzo dobrze wyważone. Dziwny katalog 100k prawdopodobnie nie będzie zauważalnym problemem, podobnie jak niektóre puste katalogi.

XFS nie jest idealny dla ogromnej liczby małych plików. Robi, co może, ale jest bardziej zoptymalizowany pod kątem przesyłania strumieniowego zapisów większych plików. Jednak ogólnie jest bardzo dobry do ogólnego użytku. Nie ma ENOSPCkolizji w indeksowaniu katalogów (AFAIK) i może obsłużyć jeden katalog z milionami wpisów. (Ale nadal lepiej jest użyć drzewa przynajmniej jednego poziomu).

Dave Chinner miał kilka uwag na temat wydajności XFS z przydzieloną ogromną liczbą i-węzłów , co doprowadziło do powolnej touchwydajności. Znalezienie wolnego i-węzła do przydzielenia zaczyna zajmować więcej czasu procesora, ponieważ wolna mapa bitowa i-węzła ulega fragmentacji. Zauważ, że nie jest to kwestia jednego dużego katalogu w porównaniu z wieloma katalogami, ale raczej kwestia wielu używanych i-węzłów w całym systemie plików. Dzielenie plików na wiele katalogów pomaga w niektórych problemach, takich jak ten, który ext4 dławił się w OP, ale nie problem polegający na śledzeniu wolnego miejsca na całym dysku. Pomaga w tym oddzielny system plików na dysk Swift w porównaniu z gigantycznym XFS na RAID5.

Nie wiem, czy btrfs jest w tym dobry, ale myślę, że tak może być. Myślę, że Facebook nie bez powodu zatrudnia swojego wiodącego programistę. : P Kilka testów, które widziałem, takich jak rozpakowywanie źródła jądra Linuksa, show btrfs robi dobrze.

Wiem, że reiserfs został zoptymalizowany do tego przypadku, ale ledwo, jeśli w ogóle, jest już utrzymywany. Naprawdę nie mogę polecić korzystania z Reiser4. Jednak eksperymentowanie może być interesujące. Ale jest to zdecydowanie najmniejszy wybór na przyszłość. Widziałem także raporty o obniżeniu wydajności w wieku reiserFS i nie ma dobrego narzędzia do defragmentacji. (google filesystem millions of small filesi spójrz na niektóre z istniejących odpowiedzi wymiany stosów).

Prawdopodobnie coś mi brakuje, więc ostatnia rekomendacja: zapytaj o to podczas awarii serwera! Gdybym musiał teraz coś wybrać, powiedziałbym, że wypróbuj BTRFS, ale upewnij się, że masz kopie zapasowe. (szczególnie jeśli używasz wbudowanej nadmiarowości wielu dysków BTRFS, zamiast uruchamiać go na macierzy RAID. Korzyści z wydajności mogą być duże, ponieważ małe pliki to zła wiadomość dla RAID5, chyba że jest to obciążenie głównie do odczytu).

W przypadku tego problemu poniżej naprawiłem (możesz potrzebować dostępu sudo do wykonania poniższych kroków):

1. Wykorzystana przestrzeń i-węzłów wynosiła 100%, którą można odzyskać za pomocą poniższego polecenia

   df -i /

System plików I-węzły IUsed IFree IUse% Zainstalowane na

/dev/xvda1            524288   524288  o     100% /

2. Musisz zwolnić program iNoted, dlatego musisz znaleźć pliki, które mają tutaj liczbę węzłów i, używając poniższego polecenia:

Spróbuj ustalić, czy jest to problem z i-węzłami:

df -ih

Spróbuj znaleźć foldery główne z dużą liczbą i-węzłów:

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

Spróbuj znaleźć określone foldery:

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

3. teraz wyzerowaliśmy folder z dużą liczbą plików. Uruchom poniższe polecenia jeden po drugim, aby uniknąć błędów (w moim przypadku właściwym folderem był / 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 {} +