- 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
źródło
Odpowiedzi:
Błąd w implementacji funkcji ext4,
dir_index
któ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.
źródło
dir_index
prawdopodobnie zabije wydajność dostępu przy plikach 70m w jednym katalogu.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
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
ENOSPC
kolizji 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
touch
wydajnoś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 files
i 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).
źródło
/
. Mamy nadzieję, że nie wpłynie to na zbyt wiele miejsc w kodzie. (Musisz upewnić się, że katalogi zostaną utworzone, jeśli utworzenie nowego pliku nie powiedzie sięENOENT
). Zapytaj podczas błędu serwera, czy istnieją inne systemy plików.W przypadku tego problemu poniżej naprawiłem (możesz potrzebować dostępu sudo do wykonania poniższych kroków):
Wykorzystana przestrzeń i-węzłów wynosiła 100%, którą można odzyskać za pomocą poniższego polecenia
df -i /
Spróbuj ustalić, czy jest to problem z i-węzłami:
Spróbuj znaleźć foldery główne z dużą liczbą i-węzłów:
Spróbuj znaleźć określone foldery:
źródło