W jaki sposób system plików nie rozróżnia wielkości liter?

Programista w mojej pracy, który przez całe życie korzystał z Linuksa, krytykował Windows za posiadanie systemu plików bez rozróżniania wielkości liter (między innymi), co według niego jest najgorszym możliwym pomysłem i nigdy nie może być korzystne. Powiedziałem, że dzieje się tak tylko dlatego, że był przyzwyczajony do systemów plików z rozróżnianiem wielkości liter, i że rozsądniej jest mieć system plików bez rozróżniania wielkości liter (część mojego rozumowania polega na tym, że mam na imię David, ale jeśli odniosłeś się do mnie david, zrobiłbym to wciąż wiem, że miałeś na myśli mnie i to samo powinno dotyczyć plików). Następnie wyjaśnił swoją pozycję, stwierdzając, że system plików bez rozróżniania wielkości liter musi zostać obciążony spadkiem wydajności.

Zastanawiam się więc ... w jaki sposób system plików bez rozróżniania wielkości liter ma dostęp do plików? Pozwól mi wyjaśnić, co myślę:

Załóżmy, że masz system plików z rozróżnianiem wielkości liter (i jądra systemu operacyjnego itp.), Tak więc w praktyce, jeśli istnieje katalog o nazwie o nazwie exampleDir, muszę wpisać w nim dokładnie cd exampleDircd. Jeśli piszę cd exampledir, powinienem otrzymać błąd, że katalog nie istnieje. Wydaje mi się, że to prosta sprawa. Kiedy wpisuję polecenie, system plików może po prostu pobrać dokładnie te znaki, które wpisałem (ignorując to, co jądro może zrobić, aby dodać bieżącą ścieżkę katalogu roboczego do łańcucha itd.) I rozpocząć przeglądanie listy dostępnych nazw plików, wykonując bezpośrednie porównaj każde imię; na przykład:

for(var i=0;i<files.length;i++) {
    if(filename == files[i]) return true;
}

Teraz interesująca część : system plików bez rozróżniania wielkości liter (zakładając zachowanie wielkości liter , jak w systemie Windows). W praktyce, jeśli istnieje katalog o nazwie o nazwie exampleDir, mógłbym wpisać cd exampleDirlub cd eXamPleDIri nadal udałoby mi się dostać do tego folderu. Naprawdę chcę wiedzieć, jak wygląda kod, aby to osiągnąć. Aby zachować wielkość liter, nazwa katalogu musi być przechowywana z jej wielkością. Czy to oznacza, że za każdym razem, gdy chcesz uzyskać dostęp do pliku po nazwie pliku , musisz wykonać dwie konwersje małymi lub dużymi literami? Jak duży wpływ na wydajność ma to przełożenie? Czy są jakieś sztuczki, które zmniejszają spadek wydajności wynikający z używania systemu plików bez rozróżniania wielkości liter? Tak wyobrażam sobie kod systemu plików, który musiałby wyglądać:

for(var i=0;i<files.length;i++) {
    if(toLowercase(filename) == toLowercase(files[i])) return true;
}

Uwaga: Ponieważ wydaje się, że nie było to jasne z mojego pytania, absolutnie nie pytam, który typ jest lepszy, ani nie pytam o zalety i wady. Mam tylko pytanie, jak (pod względem technicznym) bez uwzględniania wielkości liter zajmuje system plików z faktu, że ludzie mogą wpisać nazwę pliku z losowym przypadku.

filesystems

— Clonkex
źródło

Twoje sformułowanie jest niechlujne. Nie masz na myśli „systemu plików bez rozróżniania wielkości liter” , ale po prostu nazwy plików bez rozróżniania wielkości liter. Duża różnica.

— trociny

HFS + ma także wersję bez rozróżniania wielkości liter

— phuclv

@sawdust Przepraszamy? W jaki sposób? Nie mogę wymyślić żadnego innego znaczenia, które mogłoby to sugerować.

— Clonkex,

@ LưuVĩnhPhúc Wiem. Nie jestem pewien, dlaczego to powiedziałeś.

— Clonkex,

ponieważ jeśli ktoś „krytykował Windows za posiadanie systemu plików bez rozróżniania wielkości liter”, powinien to zrobić również w przypadku DOS, CP / M i niektórych systemów Mac

— phuclv

Odpowiedzi:

Systemy operacyjne zazwyczaj działają z uchwytami. Wywoływana jest funkcja „otwarta”, która określa nazwę pliku, i zwracany jest uchwyt. Dalsze połączenia We / Wy zajmują uchwyt, a nie nazwę pliku.

Inne funkcje wymagające nazwy pliku to tworzenie plików, wyświetlanie katalogu i usuwanie plików.

Tak więc każde uderzenie wydajności związane z nierozróżnianiem wielkości liter nie będzie miało tak naprawdę wpływu na wiele rzeczywistych operacji we / wy, a jedynie na zarządzanie plikami.

Niektóre programy używają plików blokady, aby wskazać, że zasoby są w użyciu. To może przełożyć się na wiele tworzenia i usuwania.

Jednak narzut związany z wykonaniem dwóch porównań zamiast jednego jest prawdopodobnie kwestią kilku dodatkowych instrukcji języka asemblera. Oznacza mniej niż 50 cykli. Może 500 lub 5000, jeśli pojawią się błędy w pamięci podręcznej.

Naprawdę, naprawdę nie warto się martwić, chyba że dosłownie martwisz się wydajnością tworzenia / usuwania miliardów plików w krótkim czasie. Aplikacje we / wy na wysokim dysku obejmują takie rzeczy, jak bazy danych, a bazy danych zwykle otwierają kilka bardzo dużych plików i utrzymują je otwarte podczas korzystania z bazy danych. Więc tego rodzaju aplikacje - takie, które zwykle wymagają wszystkich istniejących we / wy dysku - nie wykonują wielu wywołań, w których nazwa pliku musi zostać przeanalizowana.

Szybkość medium będzie wąskim gardłem na długo przed zbliżającym się czasem, gdy zajmą się nazwami plików.

— LawrenceC
źródło

Teraz gdzieś się dostaniemy. To ostatnie zdanie jest powodem, dla którego wybrałem to jako poprawną odpowiedź, a nie coś, co rozważałem. To stawia dodatkowy czas procesora w perspektywie i sprawia, że nie wydaje się to tak mało prawdopodobne. Zwrócę jednak uwagę: tak, jestem świadom, że po otwarciu pliku odwołujesz się do niego za pomocą uchwytu (wyobraź sobie, że każda operacja odbywa się według nazwy pliku!), A także nie jest to różnica między 1 lub 2 porównaniami, to jest różnica między porównaniem lub porównaniem a 2 wywołaniami funkcji. Niemniej jednak dobra odpowiedź.

— Clonkex

Jeśli przyjmiesz, że w samym systemie plików rozróżniana jest wielkość liter, o ile pozwala on na przechowywanie nazwy pliku bez użycia wielkich i małych liter, wówczas w przypadku niektórych operacji musi istnieć pewien rodzaj ograniczenia wydajności.

Na przykład powiedz, że masz plik, foobar.txta następnie powiesz programowi, aby go zapisał, ponieważ fooBar.txtnie sprawdza, czy już istnieje.

Dla każdego pliku utworzonego w systemie bez rozróżniania wielkości liter musi wykonać tylko jedno wyszukiwanie - dokładnie taką nazwę, jaką podałeś. Oszczędzaj, gotowe.

Dla każdego pliku utworzonego w systemie z rozróżnianiem wielkości liter musi albo wyszukać każdą kombinację „foobar” „Foobar” „fOobar” lub buforować listę plików, a następnie przekonwertować całą listę nazw plików na niższe lub wyższe spraw i przeszukaj to, aby sprawdzić, czy istnieją zduplikowane pliki. To samo dotyczy odczytu plików, jeśli dokładne dopasowanie nie zadziałało, musi sprawdzić wszystkie możliwości.

Istnieje ogromna różnica w ilości pracy, którą musi wykonać sterownik systemu plików, aby sprawdzić istnienie pliku.

Za odczytywanie nazw plików system ma znacznie mniejszą karę, w prawie wszystkich przypadkach sterownik systemu plików przekazuje listę plików do programu, który o to poprosił. Jestem pewien, że widziałem, jak ludzie wspominają, że można tworzyć „zduplikowane” nazwy plików w systemie plików NTFS przy użyciu systemu bez rozróżniania wielkości liter, takiego jak Linux i Windows, który sobie z tym radzi.

Systemy bez rozróżniania wielkości liter wymagają więcej pracy po stronie programistów, ale nieco upraszczają widok rzeczy z perspektywy użytkownika. Istnieją dwa za i przeciw obu sposobów robienia rzeczy.

Po pierwsze, widzę problem w systemach rozróżniających wielkość liter w przypadku błędów programowania zależnych od wielkości liter podczas odczytu plików. Jeśli twój program na stałe zakoduje żądanie /etc/fishi ktoś zmieni jego nazwę na /etc/Fish(lub zapomniałeś przytrzymać Shift dla „f”), wtedy pojawi się błąd, którego w innym przypadku nie wystąpiłby w systemie bez rozróżniania wielkości liter.

Chodzi o to, gdzie wkładasz wysiłek, i są kompromisy w obu sposobach robienia rzeczy.

— Mokubai
źródło

Na marginesie: jeśli kłóci się o takie błahostki, to albo próbuje cię podnieść, by bronić swojego ulubionego systemu, co najwyraźniej mu się udało, albo nie jest pewny swojego ulubionego systemu. W obu przypadkach decyzje zostały podjęte dla obu systemów z jakiegoś powodu i oba mają swoje zalety. Postawa, że „moje jest lepsze niż twoje”, na dłuższą metę nie pomaga nikomu. Po prostu zaakceptuj różnice, zobacz, jak wpływają one na rzeczy i zastanów się, w jaki sposób oba sposoby mogą działać lepiej w przyszłości.

— Mokubai

Cholera, napisałem naprawdę długi komentarz i przypadkowo kliknąłem stronę: facepalm: Cóż, w istocie chodzi o: twoją odpowiedź (co bardzo doceniam, widzę, że włożyłeś w to wiele wysiłku), pierwszy akapit wydaje się całkowicie przeciwny do tego, czego bym się spodziewał (patrz moja zredagowana odpowiedź), a jeśli chodzi o twój komentarz, zdecydowanie nie mówiłem „mój jest lepszy od twojego”. Absolutnie zgadzam się, że oba mają zalety. Rany, dlaczego wszyscy myślą, że próbowałem powiedzieć, że jedno jest lepsze od drugiego ...

— Clonkex

@Clonkex, aby zobaczyć nazwy dużych i małych liter, rzeczywisty system plików (zapisany na dysku) musi uwzględniać wielkość liter, sterownik systemu plików z drugiej strony można zaprogramować tak, aby ignorował lub omijał tę czułość i jest to tam faktyczna praca jest wykonywana. Problem, jaki widzę, polega na tym, że łączysz system plików i jego sterownik, gdy w rzeczywistości są to dwie odrębne, aczkolwiek ściśle ze sobą powiązane rzeczy.

— Mokubai

Właśnie to miałem na myśli mówiąc, że system plików nie rozróżnia wielkości liter. Tak naprawdę nie ma znaczenia, która część łańcucha (od okna wiersza polecenia cmd aż do samego systemu plików) faktycznie działa na rzecz obsługi rozróżniania wielkości liter. Chciałem tylko wiedzieć, w jaki sposób ta rozróżnienie wielkości liter jest osiągane. Wydawało się niewiarygodne, że w rzeczywistości może to być odpowiednik dla toLowercase()każdej nazwy pliku do porównania, ale LawrenceC umieścił to w perspektywie i teraz zdaję sobie sprawę, że dodatkowy czas procesora jest nieznaczny w porównaniu do oczekiwania na dysku dla IO (nawet dla dysku SSD) .

— Clonkex