maksymalna liczba plików na katalog w ext4

Zarządzam aplikacją zawierającą magazyn plików, w którym wszystkie pliki są przechowywane z nazwami plików równymi ich sumom MD5. Wszystkie pliki są przechowywane w jednym katalogu. Obecnie jest ich tysiące, ale wkrótce na serwerze powinny pojawić się miliony plików. Na obecnym serwerze działa Ubuntu 11.10 na systemie plików ext4.

Ktoś powiedział mi, że nie jest rozsądne umieszczanie wielu plików w katalogu, ponieważ spowoduje to znaczny wzrost czasu wyszukiwania i niezawodności (miał historię o maksymalnej liczbie plików, na którą może wskazywać pojedynczy katalog, co prowadzi do dużej listy z linkami). Zamiast tego zasugerował utworzenie podkatalogów z np. Podciągami nazwy pliku. Sprawi to jednak, że niektóre rzeczy w mojej aplikacji będą znacznie bardziej kłopotliwe.

Czy to nadal prawda, czy też nowoczesne systemy plików (np. Ext4) mają bardziej wydajne sposoby radzenia sobie z tym i naturalnie skalowane? Wikipedia ma pewne szczegóły na temat systemów plików, ale tak naprawdę nie mówi nic o maksymalnej liczbie plików na katalog ani o czasach wyszukiwania.

Te ext3i nowsze systemy plików obsługują hashed B-drzewo katalogów indeksowanie. Skaluje się bardzo dobrze, o ile jedyne operacje, które wykonujesz, to dodawanie, usuwanie i dostęp według nazwy. Jednak nadal zalecałbym rozbicie katalogów. W przeciwnym razie, należy utworzyć niebezpieczną pułapkę dla narzędzi ( updatedb, ls, du, i tak dalej), które wykonują inne operacje na katalogach, które wysadzają jeśli katalog ma zbyt wiele wpisów.

Istotą problemu jest przekopanie się przez i-węzeł katalogu w poszukiwaniu jednego pliku. Niektóre systemy plików robią to lepiej niż inne. Niektóre skala blisko miliardach, ale jeśli masz tylko ... 20K pliki dotarcie do tych plików jest znacznie szybszy. Ponadto duża liczba plików stwarza problemy dla niektórych narzędzi i może powodować, że tworzenie kopii zapasowych / przywracanie jest o wiele trudniejszym problemem.

Tak się składa, że ​​napotkałem dokładnie ten sam problem w naszym własnym rozwoju (md5sum jako nazwa pliku, jego skalowanie). To, co poleciłem naszym programistom, to posiekanie sznurka na kawałki. Poszli z grupami po 4, ale w systemie plików, w którym byliśmy wtedy włączeni, nawet wielu z nich sprawiałoby problemy z punktu widzenia wydajności, więc ostatecznie podzielili się na grupę 3 dla pierwszych 6 trojetów i pozostawiając resztę jako nazwa pliku w katalogu terminali.

Grupa 4: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
Grupa 3:497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

Ma to tę zaletę, że utrzymuje małe rozmiary katalogów, a ponieważ MD5sum jest dość losowy, stworzy zrównoważone drzewa katalogów. Ten ostatni katalog raczej nie uzyska więcej niż kilku plików. I nie było tak ciężko pracować z naszym kodem. Pracujemy z wieloma milionami projektów plików, więc skalowanie było dla nas bardzo ważne.

Nowoczesne systemy plików bardzo dobrze obsługują bardzo duże katalogi, nawet miliony plików. Ale konwencjonalne narzędzia nie. Na przykład wyświetlenie tak dużego katalogu z „ls” zajęłoby dość dużo czasu, ponieważ normalnie czytałby cały katalog i sortował go (chociaż możesz użyć ls -f, aby uniknąć sortowania). Pliki nie zaczną się wyświetlać, dopóki wszystkie nie zostaną odczytane. Podział nazw pomaga w niektórych przypadkach, ale nie we wszystkich (na przykład replikacja rsync może nadal wymagać zebrania całego drzewa nazw).

Czy zamiast tego sugeruję użycie bazy danych SQL? Prawdopodobnie przekształciłoby to postrzeganą słabość aplikacji w siłę.