Czy to ważne, ile plików przechowuję w jednym katalogu? Jeśli tak, to ile plików w katalogu jest za dużo i jakie są skutki posiadania zbyt wielu plików? (To jest na serwerze Linux.)

Tło: Mam witrynę z albumem ze zdjęciami, a każde przesłane zdjęcie jest zmieniane na 8-cyfrowy numer identyfikacyjny (powiedzmy a58f375c.jpg). Ma to na celu uniknięcie konfliktów nazw plików (na przykład, jeśli przesyłanych jest wiele plików „IMG0001.JPG”). Oryginalna nazwa pliku i wszelkie przydatne metadane są przechowywane w bazie danych. W tej chwili mam w katalogu obrazów około 1500 plików. To powoduje, że wyświetlenie listy plików w katalogu (przez klienta FTP lub SSH) zajmuje kilka sekund. Ale nie widzę, żeby miało to jakikolwiek inny efekt. W szczególności wydaje się, że nie ma to wpływu na to, jak szybko plik obrazu jest udostępniany użytkownikowi.

Myślałem o zmniejszeniu liczby obrazów, tworząc 16 podkatalogów: 0–9 i af. Następnie przenosiłbym obrazy do podkatalogów w oparciu o pierwszą cyfrę szesnastkową nazwy pliku. Ale nie jestem pewien, czy jest ku temu jakiś powód, z wyjątkiem okazjonalnego wyświetlania katalogu przez FTP / SSH.

FAT32 :

• Maksymalna liczba plików: 268,173,300
• Maksymalna liczba plików w folderze: 2 ¹⁶  - 1 (65535)
• Maksymalny rozmiar pliku: 2 GiB - 1 bez LFS , 4 GiB - 1 z

NTFS :

• Maksymalna liczba plików: 2 ³²  - 1 (4294967295)
• Maksymalny rozmiar pliku
  • Realizacja: 2 ⁴⁴  - 2 ⁶ bajtów (16 - 64 KiB TIB)
  • Teoretyczne: 2 ⁶⁴  - 2 ⁶ bajtów EBI (16 - 64) KiB
• Maksymalny rozmiar woluminu
  • Realizacja: 2 ³²  - 1 klastrach (256 TIB - 64 KiB)
  • Teoretycznie: 2 ⁶⁴  - 1 klastrów (1 YiB - 64 KiB)

ext2 :

• Maksymalna liczba plików: 10 ¹⁸
• Maksymalna liczba plików w katalogu: ~ 1,3 × 10 ²⁰ (problemy z wydajnością po 10 000)
• Maksymalny rozmiar pliku
  • 16 GiB (rozmiar bloku 1 KiB)
  • 256 GiB (rozmiar bloku 2 KiB)
  • 2 TiB (rozmiar bloku 4 KiB)
  • 2 TiB (rozmiar bloku 8 KiB)
• Maksymalny rozmiar woluminu
  • 4 TiB (rozmiar bloku 1 KiB)
  • 8 TiB (rozmiar bloku 2 KiB)
  • 16 TiB (rozmiar bloku 4 KiB)
  • 32 TiB (rozmiar bloku 8 KiB)

ext3 :

• Maksymalna liczba plików: min (volumeSize / 2 ¹³ , numberOfBlocks)
• Maksymalny rozmiar pliku: taki sam jak ext2
• Maksymalny rozmiar woluminu: taki sam jak ext2

ext4 :

• Maksymalna liczba plików: 2 ³²  - 1 (4294967295)
• Maksymalna liczba plików w katalogu: nieograniczona
• Maksymalny rozmiar pliku: 2 ^44-1  bajtów (16 TiB - 1)
• Wielkość maksymalna objętość: 2 ⁴⁸  - 1 256 bajty (TIB - 1)

Miałem ponad 8 milionów plików w jednym katalogu ext3. libc, readdir()który jest używany przez find,ls a większość innych metod omówione w tym wątku do listy dużych katalogów.

Powodem lsi findsą powolne w tym przypadku jest to, że readdir()odczytuje tylko 32 000 wpisów katalogu jednocześnie, więc na wolnych dyskach potrzeba wielu wielu odczytów, aby wyświetlić katalog. Istnieje rozwiązanie tego problemu prędkości. Napisałem dość szczegółowy artykuł na ten temat pod adresem : http://www.olark.com/spw/2011/08/you-can-list-a-directory-w--8-million-files-but-not-with- ls /

Kluczem do zabrania jest: użyj getdents()bezpośrednio - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html zamiast czegokolwiek opartego na libc, readdir()aby można było określić bufor rozmiar podczas odczytywania pozycji katalogu z dysku.

Mam katalog zawierający 88 914 plików. Podobnie jak ty służy do przechowywania miniatur i na serwerze Linux.

Pliki znajdujące się na liście za pośrednictwem FTP lub funkcji php działają wolno, ale wyświetlenie pliku ma również negatywny wpływ na wydajność. np. www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg ma czas oczekiwania 200–400 ms. Dla porównania na innej stronie mam około 100 plików w katalogu, obraz jest wyświetlany po ~ 40 ms oczekiwania.

Podałem tę odpowiedź, ponieważ większość ludzi właśnie napisała, jak będą działać funkcje wyszukiwania katalogów, których nie będziesz używać w folderze podręcznym - tylko statycznie wyświetla pliki, ale będzie zainteresowany wydajnością, w jaki sposób można z nich korzystać .

Zależy to trochę od konkretnego systemu plików używanego na serwerze Linux. Obecnie domyślnie jest to ext3 z dir_index, co sprawia, że ​​wyszukiwanie dużych katalogów jest bardzo szybkie.

Szybkość nie powinna zatem stanowić problemu, innego niż ten, który już zauważyłeś, a mianowicie, że aukcje potrwają dłużej.

Istnieje ograniczenie całkowitej liczby plików w jednym katalogu. Wydaje mi się, że pamiętam, że zdecydowanie działa do 32 000 plików.

Pamiętaj, że w systemie Linux, jeśli masz katalog ze zbyt dużą liczbą plików, powłoka może nie być w stanie rozwinąć symboli wieloznacznych. Mam ten problem z albumem zdjęć hostowanym w systemie Linux. Przechowuje wszystkie obrazy o zmienionym rozmiarze w jednym katalogu. Chociaż system plików obsługuje wiele plików, powłoka nie. Przykład:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

lub

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

Pracuję teraz nad podobnym problemem. Mamy hierarchiczną strukturę katalogów i używamy identyfikatorów obrazów jako nazw plików. Na przykład obraz z id=1234567jest umieszczany w

..../45/67/1234567_<...>.jpg

używając ostatnich 4 cyfr, aby określić, dokąd idzie plik.

Mając kilka tysięcy zdjęć, możesz użyć hierarchii jednego poziomu. Nasz sysadmin zasugerował nie więcej niż kilka tysięcy plików w danym katalogu (ext3) ze względu na wydajność / tworzenie kopii zapasowych / niezależnie od innych powodów, które miał na myśli.

Za to, co jest warte, właśnie utworzyłem katalog w ext4systemie plików z milionem plików, a następnie losowo uzyskałem dostęp do tych plików przez serwer WWW. Nie zauważyłem żadnej premii za dostęp do tych ponad (powiedzmy) posiadających tam tylko 10 plików.

Jest to całkowicie odmienne od mojego doświadczenia, które robiłem to ntfskilka lat temu.

Największy problem, na jaki natrafiłem, dotyczy systemu 32-bitowego. Po przekroczeniu określonej liczby narzędzia takie jak „ls” przestają działać.

Próba zrobienia czegokolwiek z tym katalogiem po przejściu przez tę barierę staje się ogromnym problemem.

Mam ten sam problem. Próba przechowywania milionów plików na serwerze Ubuntu w ext4. Zakończyłem prowadzenie własnych testów porównawczych. Okazało się, że płaski katalog działa znacznie lepiej, a jednocześnie jest o wiele prostszy w użyciu:

Napisał artykuł .

Jeśli czas poświęcony na wdrożenie schematu partycjonowania katalogu jest minimalny, jestem za nim. Za pierwszym razem, gdy będziesz musiał debugować problem polegający na manipulowaniu katalogiem zawierającym 10000 plików za pomocą konsoli, którą zrozumiesz.

Na przykład F-Spot przechowuje pliki zdjęć jako RRRR \ MM \ DD \ nazwa_pliku.ext, co oznacza, że ​​największy katalog, z którym miałem do czynienia podczas ręcznej manipulacji moją kolekcją ~ 20000 zdjęć, to około 800 plików. Dzięki temu pliki są łatwiejsze do przeglądania z aplikacji innej firmy. Nigdy nie zakładaj, że twoje oprogramowanie jest jedyną rzeczą, która będzie uzyskiwać dostęp do plików oprogramowania.

Zależy to całkowicie od systemu plików. Wiele współczesnych systemów plików używa porządnych struktur danych do przechowywania zawartości katalogów, ale starsze systemy plików często po prostu dodawały wpisy do listy, więc pobieranie pliku było operacją O (n).

Nawet jeśli system plików zrobi to dobrze, nadal jest absolutnie możliwe, że programy, które wyświetlają zawartość katalogu, mogą zepsuć się i wykonać sortowanie O (n ^ 2), więc aby zachować bezpieczeństwo, zawsze ograniczałbym liczbę plików na katalog do nie więcej niż 500.

To zależy od używanego systemu plików, a także niektórych flag.

Na przykład ext3 może mieć wiele tysięcy plików; ale po kilku tysiącach było bardzo wolno. Głównie podczas wyświetlania katalogu, ale także podczas otwierania pojedynczego pliku. Kilka lat temu zyskała opcję „htree”, która radykalnie skróciła czas potrzebny na uzyskanie i-węzła z nazwą pliku.

Osobiście używam podkatalogów, aby utrzymać większość poziomów poniżej tysiąca przedmiotów. W twoim przypadku stworzyłbym 256 katalogów z dwoma ostatnimi cyframi szesnastkowymi identyfikatora. Użyj ostatniej, a nie pierwszej cyfry, aby uzyskać równowagę obciążenia.

ext3 faktycznie ma ograniczenia wielkości katalogów i zależą od wielkości bloku systemu plików. Nie istnieje „maksymalna liczba” plików w katalogu, ale „maksymalna liczba bloków używanych do przechowywania wpisów plików w katalogu”. W szczególności rozmiar samego katalogu nie może wzrosnąć poza b-drzewo o wysokości 3, a rozwinięcie drzewa zależy od wielkości bloku. Zobacz ten link, aby uzyskać szczegółowe informacje.

https://www.mail-archive.com/[email protected]/msg01944.html

Ostatnio mnie to ugryzło w systemie plików sformatowanym za pomocą bloków 2K, który w niewytłumaczalny sposób otrzymywał wiadomości z pełnym katalogiem jądra warning: ext3_dx_add_entry: Directory index full!podczas kopiowania z innego systemu plików ext3. W moim przypadku nie można skopiować katalogu z zaledwie 480 000 plików do miejsca docelowego.

Pytanie sprowadza się do tego, co zamierzasz zrobić z plikami.

W systemie Windows każdy katalog zawierający więcej niż 2k plików ma tendencję do otwierania się dla mnie powoli w Eksploratorze. Jeśli wszystkie są plikami obrazów, więcej niż 1k ma tendencję do otwierania się bardzo powoli w widoku miniatur.

Kiedyś narzucony przez system limit wynosił 32 767. Jest teraz wyższy, ale nawet w większości przypadków jest to o wiele za dużo plików na raz.

Większość powyższych odpowiedzi nie pokazuje, że na pierwotne pytanie nie ma odpowiedzi „Jeden rozmiar dla wszystkich”.

W dzisiejszym środowisku mamy duży konglomerat różnego sprzętu i oprogramowania - niektóre są 32-bitowe, inne są 64-bitowe, niektóre są nowatorskie, a niektóre sprawdzone i prawdziwe - niezawodne i nigdy się nie zmieniają. Do tego dochodzi szereg starszych i nowszych urządzeń, starszych i nowszych systemów operacyjnych, różnych dostawców (Windows, Unixes, Apple itp.) Oraz niezliczone narzędzia i serwery. Ponieważ sprzęt został ulepszony, a oprogramowanie przekonwertowane na 64-bitową kompatybilność, koniecznie występowało znaczne opóźnienie, aby wszystkie części tego bardzo dużego i złożonego świata dobrze grały w szybkim tempie zmian.

IMHO nie ma jednego sposobu na rozwiązanie problemu. Rozwiązaniem jest zbadanie możliwości, a następnie, metodą prób i błędów, znalezienie tego, co najlepiej pasuje do konkretnych potrzeb. Każdy użytkownik musi określić, co działa w jego systemie, a nie stosować metody usuwania plików cookie.

Mam na przykład serwer multimediów z kilkoma bardzo dużymi plikami. Wynikiem jest tylko około 400 plików wypełniających dysk o pojemności 3 TB. Wykorzystuje się tylko 1% i-węzłów, ale 95% całkowitej przestrzeni jest używane. Ktoś inny, z wieloma mniejszymi plikami, może zabraknąć i-węzłów, zanim zbliży się do wypełnienia przestrzeni. (W systemach plików ext4 z reguły stosuje się 1 i-węzeł na każdy plik / katalog.) Chociaż teoretycznie całkowita liczba plików, które mogą być zawarte w katalogu, jest prawie nieskończona, praktyczność określa, że ​​ogólne użycie określa realistyczne jednostki, a nie tylko możliwości systemu plików.

Mam nadzieję, że wszystkie powyższe odpowiedzi promują myślenie i rozwiązywanie problemów, a nie stanowią barierę nie do pokonania.

Pamiętam, że uruchomiłem program, który tworzył ogromną liczbę plików na wyjściu. Pliki posortowano według liczby 30000 na katalog. Nie przypominam sobie żadnych problemów z odczytem, ​​kiedy musiałem ponownie wykorzystać wyprodukowane wyjście. Był na 32-bitowym laptopie z systemem Ubuntu Linux, a nawet Nautilus wyświetlił zawartość katalogu, choć po kilku sekundach.

System plików ext3: podobny kod w systemie 64-bitowym radził sobie dobrze z 64000 plików w katalogu.

„Zależy od systemu plików”
Niektórzy użytkownicy wspomnieli, że wpływ na wydajność zależy od używanego systemu plików. Oczywiście. Systemy plików takie jak EXT3 mogą być bardzo wolne. Ale nawet jeśli używasz EXT4 lub XFS nie można zapobiec poprzez wystawianie folder lslub findlub za pośrednictwem połączenia zewnętrznych, takich jak FTP staną się wolniejsze wolniej.

Rozwiązanie
Wolę tak samo jak @armandino . W tym celu używam tej małej funkcji w PHP do konwertowania identyfikatorów na ścieżkę pliku, która daje 1000 plików w katalogu:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

lub możesz użyć drugiej wersji, jeśli chcesz użyć znaków alfanumerycznych:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

wyniki:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Jak widać dla $int-wersji, każdy folder zawiera do 1000 plików i do 99 katalogów zawierających 1000 plików i 99 katalogów ...

Ale nie zapominaj, że wiele katalogów powoduje te same problemy z wydajnością!

Wreszcie powinieneś pomyśleć o tym, jak zmniejszyć całkowitą liczbę plików. W zależności od celu możesz używać duszków CSS do łączenia wielu małych obrazów, takich jak awatary, ikony, emotikony itp. Lub jeśli używasz wielu małych plików innych niż media, rozważ połączenie ich np. W formacie JSON. W moim przypadku miałem tysiące mini-skrzynek i ostatecznie postanowiłem połączyć je w paczkach po 10.

Szanuję, że to nie do końca odpowiada na pytanie, ile jest za dużo, ale pomysłem na rozwiązanie problemu długoterminowego jest to, że oprócz przechowywania oryginalnych metadanych plików, przechowuj również folder na dysku, w którym jest przechowywany - normalizuj z tego fragmentu metadanych. Gdy folder wzrośnie powyżej pewnego limitu, który jest dla Ciebie wygodny pod względem wydajności, estetyki lub jakiegokolwiek innego powodu, po prostu utwórz drugi folder i zacznij tam upuszczać pliki ...

Wystąpił podobny problem. Próbowałem uzyskać dostęp do katalogu zawierającego ponad 10 000 plików. Zbyt długo trwało tworzenie listy plików i uruchamianie dowolnego rodzaju poleceń na dowolnym z plików.

Wymyśliłem mały skrypt php, aby zrobić to dla siebie i próbowałem znaleźć sposób, aby zapobiec przekroczeniu limitu czasu w przeglądarce.

Poniżej znajduje się skrypt php, który napisałem w celu rozwiązania problemu.

Wyświetlanie plików w katalogu ze zbyt dużą liczbą plików do FTP

Jak to komuś pomaga

Nie odpowiedź, ale tylko kilka sugestii.

Wybierz bardziej odpowiedni FS (system plików). Ponieważ z historycznego punktu widzenia wszystkie twoje problemy były na tyle mądre, że kiedyś były kluczowe dla FS rozwijających się przez dziesięciolecia. Mam na myśli, że bardziej nowoczesny FS lepiej wspiera twoje problemy. Najpierw utwórz tabelę decyzji porównawczych na podstawie ostatecznego celu z listy FS .

Myślę, że nadszedł czas na zmianę paradygmatów. Dlatego osobiście sugeruję użycie systemu FS zorientowanego na system rozproszony , co oznacza brak ograniczeń co do rozmiaru, liczby plików itp. W przeciwnym razie wcześniej czy później pojawią się nowe, nieprzewidziane problemy.

Nie jestem pewien, czy zadziała, ale jeśli nie wspominasz o eksperymentach, wypróbuj AUFS w swoim obecnym systemie plików. Wydaje mi się, że ma możliwości naśladowania wielu folderów jako pojedynczego folderu wirtualnego.

Aby pokonać ograniczenia sprzętowe, możesz użyć RAID-0.

Nie ma jednej liczby, która byłaby „zbyt duża”, o ile nie przekroczyłaby limitów systemu operacyjnego. Jednak im więcej plików w katalogu, niezależnie od systemu operacyjnego, tym dłużej trwa dostęp do dowolnego pojedynczego pliku, a w większości systemów operacyjnych wydajność jest nieliniowa, więc znalezienie jednego pliku na 10 000 zajmuje więcej niż 10 razy dłużej następnie, aby znaleźć plik w 1000.

Drugorzędnymi problemami związanymi z posiadaniem wielu plików w katalogu są awarie rozszerzania kart wieloznacznych. Aby zmniejszyć ryzyko, możesz rozważyć zamówienie katalogów według daty przesłania lub innego przydatnego fragmentu metadanych.