Czy ten sam dysk ext4 można podłączyć z dwóch hostów, z jednego tylko do odczytu?

Wiem, że podłączenie tego samego dysku z systemem plików ext4 z dwóch różnych serwerów (jest to wersja iSCSI vloume) prawdopodobnie uszkodzi dane na dysku. Moje pytanie brzmi: czy to zrobi różnicę, jeśli jeden z serwerów zamontuje dysk tylko do odczytu, a drugi zamontuje go do odczytu i zapisu?

Wiem, że do tego można użyć OCFS2 lub polubień i że mogę wyeksportować dysk z NFS, aby był dostępny dla innego serwera, ale chciałbym wiedzieć, czy proponowana konfiguracja będzie działać.

linux mount ext4

— Fernando
źródło

Może działać tylko wtedy, gdy oba są montowane tylko do odczytu (a przez to mam na myśli prawdziwą opcję tylko do odczytu, która nie pisze). Gdy tylko jedna strona montuje odczyt-zapis, druga strona (montowany tylko do odczytu) nie oczekuje zmian po drugiej stronie (montowany odczyt-zapis), a zatem odczytuje uszkodzone dane. Potrzebujesz systemu plików obsługującego klastry lub pojedynczego serwera, który udostępnia system plików innym użytkownikom.

— frostschutz

@frostschutz Tak, oba ro będą działać, ale nie bez lew, ponieważ ro-mount ext4 zapisuje na rzeczywistym dysku (potrzebuje pętli ro i nakładki dla każdego).

— Ned64

Podzielę się tutaj przypadkiem użycia: serwer fizyczny i serwer wirtualny współużytkują dysk fizyczny z przekazywaniem dysku. Serwer wirtualny montuje dysk jako rw. Chciałbym skopiować dużą ilość danych z dysku, ale sieć jest zbyt wolna. Byłoby wspaniale, gdybym mógł zamontować dysk fizyczny jako ro w systemie operacyjnym hosta i skopiować dane na zewnętrzny dysk USB. Serwer hosta ma tylko jeden kontroler USB, więc przejście przez PCI nie jest opcją.

— Zhuoyun Wei,

Odpowiedzi:

Nie. Nie da spójnych wyników na kliencie tylko do odczytu z powodu buforowania. Zdecydowanie nie jest do tego przeznaczony. Można oczekiwać, że błędy we / wy zostaną zwrócone do aplikacji. W kodzie prawdopodobnie znajduje się pewna liczba niedopatrzeń, które mogą spowodować awarię jądra lub uszkodzenie pamięci używanej przez dowolny proces.

Ale co najważniejsze, ext4 odtwarza dziennik nawet przy montowaniu tylko do odczytu. Zatem montowanie tylko do odczytu będzie nadal zapisywać na bazowym urządzeniu blokowym. Byłoby to niebezpieczne, nawet gdyby oba wierzchowce były tylko do odczytu :).

— sourcejedi
źródło

Jak mówisz, montowanie tylko do odczytu nie gwarantuje, że system plików pozostanie nietknięty. Jeśli nadal chcesz spróbować dla „edukacyjnych” celów bez podejmowania ryzyka, należy ustawić urządzenie tylko do odczytu: blockdev --setro /dev/sda1.

— Totor

To ciekawe informacje na temat montażu ext4. Podejrzewam, że można uniknąć tego problemu, wymuszając podłączenie ext2 tylko do odczytu?

— Bananguin

Znalazłem ten fragment kodu, który pozwala mi zamontować urządzenie blokujące tylko do odczytu na maszynie wirtualnej: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/…

— isaaclw

Pozwoli to uniknąć uszkodzenia danych, ale prawdopodobnie nie będzie to, co chcesz zrobić. Nigdy nie zauważyłem żadnych problemów z montowaniem woluminu tylko do odczytu w innym węźle. Nawet jeśli coś nie pasuje do węzła ro, co zwykle rzuca „nieoczekiwany darmowy i-węzeł, uruchom e2fsck” lub podobny w / var / log / messages. Jeśli coś jest nieoczekiwanie nieoczekiwane w niekrytycznym systemie plików („/ opt / mySpecialmount”), zwykle Linux po prostu zamontuje wolumin tylko do odczytu (hej, już tam jesteśmy). Jeśli bardzo martwisz się efektem buforowania, możesz spróbować uruchomić jakiś system drop_caches / vfs_cache_pressure.

Aby uniknąć ponownego odtwarzania dziennika, dodaj „noload” do argumentów montowania, zrób to wraz z błędami = remount-ro (tylko po to, aby zachować ostrożność).

To powiedziawszy, są szanse, że jeśli nie masz nic przeciwko zamontowaniu go tylko do odczytu, prawdopodobnie jest to tylko odniesienie dla drugiego węzła, w którym to przypadku NFS lub smbfs rozwiązałoby problem i jest zaprojektowany dla nieco większej współbieżności niż ext3 / 4 byłoby. Jeśli potrzebujesz wydajności, możesz przyjrzeć się klastrowanemu systemowi plików (nieco więcej kosztów administracyjnych, ale jest tam, jeśli wydajność naprawdę jest czymś, czego potrzebujesz).

— Bratchley
źródło

„ Pozwoli to uniknąć uszkodzenia danych ”: może nie być, zobacz odpowiedź Sourcejedi i mój komentarz .

— Totor

"pomijanie powtórki dziennika spowoduje, że system plików będzie zawierał niespójności, które mogą prowadzić do wielu problemów" - man mount. Mogę sobie wyobrazić, że istnieją aplikacje, które wykrywają i / lub tolerują niespójne dane w swoich plikach, ale jak dotąd nie wspomniałeś o żadnym takim zastrzeżeniu :).

— sourcejedi

@sourcejedi Mówią to, ponieważ próbują powiedzieć ludziom o ryzyku skutecznego odsunięcia czasopisma na bok. Jest to w porządku, ponieważ założono, że drugi węzeł będzie wykonywał pracę dziennika dla drugiego węzła, staramy się po prostu uniknąć podwójnej pracy. Robimy to na jednym z naszych serwerów programistycznych (nie mój wybór, zrobiłbym NFS) i mieliśmy to zamontowane bez nawet drop_cache przez prawie rok bez żadnych problemów. Oboje wspomnieliśmy, że nieaktualne wpisy pamięci podręcznej FS mogą renderować stare dane, ale ostatecznie to administrator decyduje, czy jest to wykonalne.

— Bratchley,

Nie zamierzam wyliczyć wszystkich błędów w powyższym komentarzu. Ale jako jeden punkt danych nie chodzi tylko o nieaktualne dane plików w pamięci podręcznej VFS. ext4 będzie także mieć pamięć podręczną wewnętrznych struktur danych systemu plików („metadanych”). Możesz w końcu odczytać dane z usuniętego pliku, który został następnie nadpisany przez nowy plik. Jest to rodzaj zastrzeżenia, o którym naprawdę chcesz wiedzieć z góry, nawet jeśli zdarzy się to rzadko.

— sourcejedi

Patrząc wstecz na twój komentarz, myślę, że możesz próbować odwoływać się do buforowania na poziomie bloku, czyli buforowania we / wy urządzenia blokowego w pamięci. W tym przypadku, to nie jest buforowanie, który występuje w samej, to buforowanie metadanych Z samego metadanych. Istnieje również poza wszelkimi sterownikami systemu plików, więc ext4 / btrfs / etc nie zarządza nim.

— Bratchley,