Które sieciowe systemy plików nieprawidłowo implementują blokowanie?


8

Jako częstą przyczynę uszkodzenia plików dokumentacja często podaje jako przyczynę „NFS, który nie implementuje poprawnie blokowania na poziomie plików” lub coś podobnego, np. Dla SQLite:

Jak uszkodzić plik bazy danych SQLite , akapit 2.1

2.1 Systemy plików z uszkodzonymi lub brakującymi implementacjami blokad

SQLite zależy od bazowego systemu plików, aby wykonać blokowanie, tak jak dokumentuje. Ale niektóre systemy plików zawierają błędy w logice blokowania, przez co blokady nie zawsze zachowują się tak, jak reklamowano. Dotyczy to w szczególności sieciowych systemów plików, w szczególności NFS. Jeśli SQLite jest używany w systemie plików, w którym prymitywy blokujące zawierają błędy, i jeśli dwa lub więcej wątków lub procesów próbuje uzyskać dostęp do tej samej bazy danych w tym samym czasie, może to spowodować uszkodzenie bazy danych.

O tym - lub coś w tym rodzaju - często wspominano przez ponad dekadę, zwykle w mieszanych środowiskach Windows / Unix. Jednak nigdy nie znalazłem żadnego wskazania, które sieciowe systemy plików (lub kombinacje klient / serwer) faktycznie są zagrożone.

Co mogę powiedzieć moim klientom?


1
Nie chodzi tylko o system plików, ale o protokół udostępniania (NFS nie jest systemem plików pomimo nazwy). Samba wykonuje blokowanie zapisu.
Frank Thomas

więc byłby to problem między niektórymi klientami / serwerami?
peterchen

to problem z serwerem. ale w większości masz rację. NFS powinien informować o istniejącym systemie plików, aby wdrożyć blokadę, gdy plik jest otwierany do zapisu. tym systemem plików może być EXT, BTRFS, MurderFS, NTFS lub cokolwiek innego. Wszyscy FS muszą poradzić sobie z blokowaniem zapisu, ale protokół udostępniania jest odpowiedzialny za brokowanie między żądaniem sieci a semantyką specyficzną dla systemu plików. niestety wydaje się, że NFS nie robi tego dobrze. Nie jestem pewien dlaczego, ale zgaduję, że jest to problem ze sposobem, w jaki abstrahuje od faktycznych operacji FS.
Frank Thomas

Odpowiedzi:


2

Które sieciowe systemy plików nieprawidłowo implementują blokowanie?

Uważam, że poprawna odpowiedź jest w skrócie: „Wszystkie”.

Należy to zakwalifikować do kontekstu wielu procesów na wielu komputerach uzyskujących dostęp do tej samej bazy danych przez sieć. Nie powinno być problemu, gdy wszystkie procesy uzyskujące dostęp do bazy danych działają na tym samym komputerze, jeśli silnik bazy danych (SQLite) używa narzędzi wykluczających, takich jak semafory lub muteks (i używa ich poprawnie ...).

Powodem tego jest to, że informacje o tym, co jest zablokowane, są zwykle przechowywane w kontekście „procesu X blokuje Y”. Może to działać bardzo dobrze, gdy wszystkie procesy są wykonywane na tym samym komputerze, ale niezbyt dobrze, gdy są na różnych komputerach.

Gdy proces z jednego komputera uzyskuje dostęp do pliku na innym komputerze, lokalny system operacyjny sam zastępuje proces zdalny, w efekcie działając jako agent dla procesu, o którym nic nie wie. Może nawet mieć trudności z rozróżnieniem dwóch różnych procesów wykonywanych na tym samym komputerze zdalnym i pomylić jeden z drugim.

Aby poprawnie zablokować pliki, cały plik lub jego część, naprawdę potrzebowałby jednego systemu operacyjnego, który działa na wszystkich zaangażowanych komputerach ze scentralizowanym repozytorium danych do blokowania plików. Niestety, ani Linux, ani Windows nie mogą tego zrobić w ogólnym przypadku.

Lepszy traktat na temat SQLite można znaleźć w sekcji „Jak uszkodzić pliki bazy danych” w starszym artykule Blokowanie i współbieżność plików w SQLite w wersji 3 . Te szczegóły, które system wywołuje za pomocą SQLite, aby zapewnić współbieżność w systemach Windows i Linux, zarówno w celu blokowania sekcji plików, jak i wypłukiwania zaktualizowanych danych z komputera do bazy danych. Wszystkie wymienione funkcje działałyby dobrze tylko w kontekście jednego komputera. Odpowiednio, ten artykuł zawiera zdanie „Najlepszą obroną jest nie używanie SQLite do plików w sieciowym systemie plików”.

Zauważ, że problem opróżniania danych do bazy danych jest szczególnie niepokojący, ponieważ system operacyjny zwykle opóźnia zapis, więc może się zdarzyć, że proces aktualizacji opróżnił dane i zwolnił blokadę, ale nowe dane mogły jeszcze nie przybyć do bazy danych, gdy inny proces próbował ją odczytać, co kończy się łatwo uszkodzoną bazą danych.

Więcej informacji można znaleźć w artykule SQLite Atomic Commit In SQLite , w sekcji Rzeczy, które mogą pójść źle . Dodaje przypadek, w którym różne procesy i komputery mogą korzystać z różnych mechanizmów blokowania, w których jeden nie blokuje drugiego.

W systemach zarządzania bazami danych, które rozwiązały ten problem, takich jak Oracle lub SQL Server, rozwiązaniem jest wyznaczenie jednego konkretnego komputera jako jedynego, który może aktualizować bazę danych, więc blokowanie jest znacznie uproszczone. Inne systemy sieci komputerowych, takie jak Apache Hadoop, dostarczają własne mechanizmy blokujące w celu rozwiązania tych problemów.

Innym ciekawym artykułem jest O łamaniu blokowania plików .


Pobiłeś mnie do tego, mówiąc „Wszyscy”. A twoje linki są bardzo pouczające. O wiele bardziej obszerna odpowiedź, niż bym sobie udzielił.
Tonny

Możliwe jest , aby działało to ... ale potrzebujesz czegoś naprawdę ciężkiego, takiego jak rozproszona usługa blokowania Paxos . Z pewnością nie jest to coś, co zapewnia przeciętny sieciowy system plików klasy konsumenckiej.
Kevin
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.