Jakieś ograniczenia dotyczące posiadania wielu plików w katalogu w Mac OS X?


9

Mam ponad 100 000 plików w katalogu w moim MacOS X i wygląda na to, że mój skrypt odczytuje w nich plik.

Czy są jakieś ograniczenia lub zalecenia dotyczące posiadania tak wielu plików? Czy powinienem podzielić je na niektóre katalogi?

Ograniczeniem, które znalazłem, było to, że nie mogę mv * foodla wszystkich 100 000 plików. Pokazuje błąd, mówiąc „zbyt długi argument”. Działa z około mniej niż 20 000 plików.


Obecnie mam w katalogu 380 000 plików i zdaję sobie sprawę, że nawet otwarcie pliku zajmuje ponad 10 sekund. Zdecydowałem się oddzielić je do niektórych katalogów.
Daisuki Honey

1
System plików HFS + powinien być w stanie przechowywać i uzyskiwać dostęp do dużej liczby plików w katalogu według ich pełnej nazwy bez większych problemów. Ale musisz uważać za pomocą symboli wieloznacznych. Gdy używasz *lub ?jako argumentu polecenia, system operacyjny przeszukuje cały katalog w poszukiwaniu pasujących plików (powoli), a następnie zastępuje twój argument listą wszystkich pasujących plików (długich), które następnie przekazuje do Komenda. Lepiej radzisz sobie z pętlą lub kilkoma poleceniami mv, np mv a* foo && mv b* foo.
Matthias Fripp

Odpowiedzi:


1

Zgodnie z odpowiedzią dotyczącą przepełnienia stosu i szczegółowymi szczegółami na stronie Apple , pojedynczy folder może zawierać do 2,1 miliarda elementów.

To powiedziawszy, tylko dlatego, że może pomieścić do 2,1 miliarda przedmiotów, nie oznacza, że ​​może utrzymać wydajność na tym poziomie. Według Wikipedii ; nacisk jest mój:

Plik katalogu, który przechowuje wszystkie rekordy plików i katalogów w jednej strukturze danych, powoduje problemy z wydajnością, gdy system umożliwia wielozadaniowość, ponieważ tylko jeden program może zapisywać do tej struktury jednocześnie, co oznacza, że ​​wiele programów może czekać w kolejce z powodu jednego programu „zawieszającego” system. Jest to również poważny problem z niezawodnością, ponieważ uszkodzenie tego pliku może zniszczyć cały system plików.

Tak więc wydajność jest naturalnie obniżona, ponieważ plik katalogu może być używany tylko przez jeden program na raz. A jeśli katalog powiększy się, ryzyko / pogorszenie spowodowane tym problemem będzie tylko rosło; więcej plików oznacza większą szansę dla programów na dostęp do plików w tym jednym katalogu. Dalsze potwierdzenie tego pomysłu tutaj ; znowu nacisk jest mój:

Plik katalogu jest skomplikowaną strukturą. Ponieważ przechowuje wszystkie informacje o plikach i katalogach, wymusza serializację systemu plików - nie jest to idealna sytuacja, gdy istnieje duża liczba wątków chcących wykonać operacje wejścia / wyjścia pliku. W systemie HFS każda operacja tworzenia pliku lub modyfikacji pliku w jakikolwiek sposób musi zablokować plik katalogu, co uniemożliwia innym wątkom dostęp do pliku katalogu tylko do odczytu. Dostęp do pliku katalogu musi mieć jeden pisarz / wielu liderów.


Dzięki wielkie. Rozumiem, że dostęp do pliku katalogu będzie wąskim gardłem i może powodować poważne problemy z wydajnością, szczególnie w przypadku wielozadaniowości.
Daisuki Honey

@DaisukiHoney Nie ma za co! Jeśli więc uznasz moją odpowiedź za pomocną, pamiętaj o jej głosowaniu. A jeśli to rozwiązało problem, pamiętaj o zaznaczeniu go jako takiego.
JakeGould

Tak, zdecydowanie głosuję na twoją odpowiedź i zaznaczam ją. Jeszcze raz wielkie dzięki.
Daisuki Honey

W Wikipedii sekcje zacytowanie mówimy o granicach skalowalności na systemie plików, a nie na katalogu: istnieje tylko jeden plik katalogu na systemie plików i dostęp musi serialize wszystko na ten temat. Jest to dość nieistotne dla pytania.
poolie

@poolie Pytanie dotyczy każdego katalogu, który istnieje w systemie plików. Plik katalogu istnieje dla każdego systemu plików, ale sam katalog istnieje również w tym samym systemie plików. Ma to znaczenie dla pytania dotyczącego ponad 10 000 plików w katalogu, który istnieje w jednym systemie plików. Ale to pytanie ma ponad 2 lata, więc dziękuję za link do Wiki. Zaktualizowałem swoją odpowiedź, dodając nowe sformułowanie, a także bezpośredni link do danej sekcji.
JakeGould

4

Krótka odpowiedź: Cóż, jeśli czytasz 100 000 plików, mogę oczekiwać, że skrypt będzie działał wolno.

Długa odpowiedź: Aby dokładniej odpowiedzieć na to pytanie, musisz spojrzeć na system plików na komputerze Mac. Komputery Mac używają HFS + ( Hierarchical File System Plus ), który jest nowoczesnym systemem plików, który ma ograniczenia, ale tylko w ekstremalnych sytuacjach.

Z mojego doświadczenia wynika, że ​​przypomina system plików z księgowaniem Linux EXT. Obsługuje katalogi instalacyjne, uprawnienia typu UNIX itp. Adresował pliki w formacie 32-bitowym, dzięki czemu maksymalna liczba plików, które mogą być przechowywane w woluminie 4 294 967 295, zgodnie z tym źródłem.

System plików zaczyna pękać z plikami większymi niż 8 EB w nowoczesnych systemach oraz do 2,1 miliarda plików i folderów w jednym miejscu, jak opisano tutaj .

Biorąc pod uwagę sposób, w jaki HFS + - lub tak naprawdę dowolny system plików jest skonfigurowany pod tym względem - posiadanie dużej liczby plików w folderze nie powinno robić niczego „dziwnego”.

Szczerze mówiąc, nie sądzę, aby poprawiła się wydajność dystrybucji plików w bardziej złożonej hierarchii folderów. W rzeczywistości ta technika może być mniej wydajna, ponieważ skrypt musiałby wywoływać zmiany katalogów w trakcie procesu.


Dobrze. Myślałem o zmianie hierarchii katalogów, ale powoduje to bardziej skomplikowany algorytm i podejrzewam, że znacznie poprawiłem wydajność. Dziękuję za odpowiedź. Obecnie mam 200 000 plików w katalogu i na końcu może mieć 1 000 000. Mam nadzieję, że działa dobrze bez tego złego działania.
Daisuki Honey

@DaisukiHoney Jeśli pracujesz z tyloma plikami, warto sprawdzić, czy możesz podzielić rzeczy na katalogi. Na tym etapie może to być trudne, ale może sprawić, że będzie trochę bardziej stabilnie.
JakeGould

@JakeGould Dzięki za radę. Myślałem o restrukturyzacji, ponieważ mogę dodać więcej plików. Dzięki.
Daisuki Honey
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.