Jak rozwiązać limit liczby podkatalogów Linux?

Mam stronę internetową, w której będą przechowywane obrazy profilów użytkowników. Każdy obraz jest przechowywany w katalogu (Linux) specyficznym dla użytkownika. Obecnie mam bazę klientów ponad 30, co oznacza, że ​​będę miał ponad 30 folderów. Ale mój obecny system Linux (ext2 / ext3) nie obsługuje tworzenia więcej niż 32000 katalogów. Jak sobie z tym poradzić? Nawet faceci z YouTube mają ten sam problem z miniaturami wideo. Ale rozwiązali to, przechodząc do ReiserFS. Czy nie możemy znaleźć lepszego rozwiązania?

Aktualizacja: Zapytani w IRC, ludzie pytali o uaktualnienie go do ext4, który ma limit 64k i oczywiście możesz go nawet ominąć . Lub hakowanie jądra w celu zmiany limitu.

Aktualizacja: Co powiesz na podzielenie bazy użytkowników na foldery na podstawie zakresu identyfikatora użytkownika. Oznacza to 1-1000 w jednym folderze, 1000-2000 w innym podobnym. To wydaje się proste. Co powiecie chłopaki?

Szczerze mówiąc, czy nie ma innego sposobu?

Limit ten dotyczy poszczególnych katalogów, a nie całego systemu plików, więc można obejść ten problem, dzieląc rzeczy dalej. Na przykład zamiast umieszczać wszystkie podkatalogi użytkowników w tym samym katalogu, dzieląc je na dwa pierwsze znaki nazwy, aby uzyskać coś takiego:

top_level_dir
|---aa
|   |---aardvark1
|   |---aardvark2
|---da
|   |---dan
|   |---david
|---do
    |---don

Jeszcze lepiej byłoby stworzyć jakąś formę skrótów nazw i użyć jej do podziału. W ten sposób uzyskasz lepszą rozpiętość między katalogami zamiast, z przykładem pierwszych liter, „da” jest bardzo pełny, a „zz” całkowicie pusty. Na przykład, jeśli weźmiesz nazwę CRC lub MD5 i użyjesz pierwszych 8 bitów, otrzymasz coś takiego:

top_level_dir
|---00
|   |---some_username
|   |---some_username
|---01
|   |---some_username
...
|---FF
|   |---some_username

W razie potrzeby można to rozszerzyć na dalsze głębokości, np. Jeśli używasz nazwy użytkownika, a nie wartości skrótu:

top_level_dir
|---a
|   |---a
|       |---aardvark1
|       |---aardvark2
|---d
    |---a
    |   |---dan
    |   |---david
    |---o
        |---don

Ta metoda jest używana w wielu miejscach, takich jak pamięć podręczna kałamarnicy, aby skopiować przykład Ludwiga i lokalne pamięci podręczne przeglądarek internetowych.

Jedną ważną rzeczą do zapamiętania jest to, że z ext2 / 3 zaczniesz napotykać problemy z wydajnością, zanim zbliżysz się do limitu 32 000, ponieważ katalogi są przeszukiwane liniowo. Przeniesienie do innego systemu plików (na przykład ext4 lub reiser) usunie tę nieefektywność (reiser przeszukuje katalogi z algorimth z podziałem binarnym, więc długie katalogi są obsługiwane znacznie wydajniej, ext4 też może to zrobić), a także ze stałym limitem na katalog.

Jeśli jesteś związany z ext2 / ext3, jedyną możliwością, jaką widzę, jest podzielenie danych na partycje. Znajdź kryterium, które dzieli dane na porcje o podobnej wielkości, które można zarządzać.

Jeśli chodzi tylko o zdjęcia profilowe, zrobiłbym:

1. Użyj skrótu (np. SHA1) obrazu
2. Użyj SHA1 jako nazwy pliku i katalogu

Na przykład pamięć podręczna SQUID robi to w ten sposób:

f / 4b / 353ac7303854033

Katalog najwyższego poziomu to pierwsza cyfra szesnastkowa, drugi poziom to kolejne dwie cyfry szesnastkowe, a nazwa pliku to pozostałe cyfry szesnastkowe.

Czy nie mamy lepszego rozwiązania?

Masz lepsze rozwiązanie - użyj innego systemu plików, dostępnych jest mnóstwo plików, z których wiele jest zoptymalizowanych do różnych zadań. Jak zauważyłeś, ReiserFS jest zoptymalizowany do obsługi wielu plików w katalogu.

Zobacz tutaj, aby porównać systemy plików.

Ciesz się, że nie utknąłeś z NTFS, który jest naprawdę fatalny dla wielu plików w katalogu. Polecam JFS jako zamiennik, jeśli nie masz ochoty używać stosunkowo nowego (ale podobno stabilnego) ext4 FS.

Czy zdjęcie profilowe jest małe? Co powiesz na umieszczenie go w bazie danych wraz z resztą danych profilu? To może nie być najlepsza opcja dla Ciebie, ale warto rozważyć ...

Oto (starszy) oficjalny dokument Microsoft na ten temat: Do BLOBA lub nie do BLOBA .

Zhakowałem małą galerię internetową, w której znalazłem odmianę tego problemu; „Tylko” miałem ~ 30 000 obrazów w katalogu pamięci podręcznej, co okazało się dość powolne (ext2 używa indeksów katalogów, jak pamiętam).

Skończyło się na zrobieniu czegoś w następujący sposób:

def key2path(key):
    hash = md5(key)
    return os.path.join(hash[0], hash[1], key)

Spowoduje to podział danych na 256 katalogów, co zapewnia szybkie wyszukiwanie katalogów dla każdego z trzech poziomów.

• Wybrałem użycie MD5 zamiast SHA-1, ponieważ MD5 gwarantuje inne wyjście, jeśli zmienisz dowolne 12 bitów po 32, więc uważam, że dobrze pasuje do haszowania nazw użytkowników, katalogów i innych krótkich rzeczy. I jest też szybki ...
• Nie uwzględniam całego skrótu, ponieważ wygeneruje on zbyt wiele katalogów i będzie skutecznie w kółko usuwał pamięć podręczną dysku.

Nie jest to natychmiastowa odpowiedź na twój problem, ale czymś, na co warto zwrócić uwagę w przyszłości, jest powiązany projekt OpenBSD o nazwie „Epitome”

Epitome to silnik, który zapewnia usługi przechowywania pojedynczej instancji, adresowalnej pamięci masowej oraz usługi deduplikacji.

Wszystkie twoje dane są przechowywane w magazynie danych jako bloki mieszane, usuwając nieunikalne bloki, aby zmniejszyć zużycie miejsca, i pozwala zasadniczo zapomnieć o mechanizmie przechowywania, ponieważ możesz po prostu poprosić o zawartość z magazynu danych przez UUID.

Epitome jest obecnie w fazie eksperymentalnej, ale na co należy zwrócić uwagę w przyszłości.

Zasadniczo chcesz unikać katalogów z dużą liczbą plików / katalogów. Główną przyczyną jest to, że interpretacja symboli wieloznacznych w wierszu poleceń spowoduje błędy „Zbyt wiele argumentów”, co spowoduje wiele bólu podczas próby pracy z tymi katalogami.

Poszukaj rozwiązania, które tworzy głębsze, ale węższe drzewo, np. Tworząc podfoldery, jak inni to opisali.

Mieliśmy podobny problem, rozwiązaniem - jak wspomniano wcześniej - jest stworzenie hierarchii katalogów.

Oczywiście, jeśli masz złożoną aplikację, która opiera się na płaskiej strukturze katalogów, prawdopodobnie będziesz potrzebować dużo łatania. Warto więc wiedzieć, że istnieje obejście tego problemu, użyj dowiązań symbolicznych, które nie mają wspomnianego limitu 32k. Masz mnóstwo czasu, aby naprawić aplikację ...

Dlaczego nie zastosować metody znacznika czasu, a następnie wybrać opcję przepełnienia.

Na przykład

Powiedzmy, że twój znacznik czasu to: 1366587600

Pomiń 2 ostatnie cyfry (inaczej stanie się to trochę niedorzeczne). Podziel znaczek na zestawy 4 (liczba katalogów nie powinna przekraczać 9999 - jeśli chcesz, możesz go rozdzielić inaczej).

To powinno dać ci coś takiego:

/files/1366/5876/

Następnie sprawdź również ilość w katalogu przed przesłaniem, jeśli pobiera dużą liczbę przesłanych plików (tj. 32000 + na 100 sekund), a następnie iteruj katalog po drugiej lub liście, na przykład:

/files/1366/5876/a/file.txt

lub

/files/1366/5876/00/file.txt

Następnie zaloguj użytkownika znacznik czasu + litera lub pełny kod ścieżki do bazy danych wraz z użytkownikiem i powinieneś zostać ustawiony.

pathstamp: 1366587600 lub 13665876a (jeśli używasz liter).

To kończy się dużą liczbą katalogów, ale może być naprawdę przydatne do obsługi poprawek plików. Na przykład, jeśli użytkownik chce użyć nowego zdjęcia profilowego, nadal ma starą wersję ze znacznikiem czasu starszego, na wypadek, gdyby chciał cofnąć zmiany (nie jest to tylko nadpisanie).

Sugeruję podjęcie decyzji, ile maksymalnych podkatalogów chcesz (lub możesz) mieć w folderze nadrzędnym.

Następnie musisz przekonwertować identyfikator użytkownika, aby zaczynał się od 1.

Następnie możesz zrobić: modulo = currentId % numberOfSubdirectories

modulobędzie teraz zawierać numer podkatalogu, który nigdy nie będzie większy niż numberOfSubdirectorieszostał wybrany.

Rób co chcesz z modulo, na przykład haszuj.

Również w ten sposób podkatalogi zostaną wypełnione liniowo.