Kann dieselbe ext4-Festplatte von zwei Hosts aus bereitgestellt werden, von denen einer schreibgeschützt ist?

Ich weiß, dass das Mounten derselben Festplatte mit einem ext4-Dateisystem von zwei verschiedenen Servern (es ist ein iSCSI-Vloume) wahrscheinlich Daten auf der Festplatte beschädigen wird. Meine Frage ist , ob es einen Unterschied macht, ob einer der Server die Festplatte schreibgeschützt und der andere schreibgeschützt einbindet.

Ich weiß, dass OCFS2 oder ähnliches dafür verwendet werden könnte und dass ich die Festplatte mit NFS exportieren könnte, um auf den anderen Server zugreifen zu können, aber ich möchte wissen, ob das von mir vorgeschlagene Setup funktioniert.

linux mount ext4

— Fernando
quelle

Es könnte nur funktionieren, wenn beide schreibgeschützt gemountet sind (und damit meine ich echt schreibgeschützt, dass nicht geschrieben wird). Sobald eine Seite Lese- / Schreibzugriff hat, erwartet die andere Seite (schreibgeschützt) keine Änderungen von der anderen Seite (schreibgeschützt) und liest daher beschädigte Daten. Was Sie benötigen, ist ein clusterfähiges Dateisystem oder ein einzelner Server, der ein Netzwerkdateisystem für das andere verfügbar macht.

— Frostschutz

@frostschutz Ja, beide ro funktionieren, aber nicht ohne Tricks, da ext4s ro-mount auf die tatsächliche Festplatte schreibt (benötigt jeweils eine ro-Schleife und ein Overlayfs).

— Ned64,

Ich werde hier einen Anwendungsfall teilen: Ein physischer Server und ein virtueller Server teilen sich eine physische Festplatte mit Festplatten-Pass-Through. Der virtuelle Server hängt die Festplatte als rw ein. Ich möchte eine große Datenmenge von der Festplatte kopieren, aber das Netzwerk ist zu langsam. Es wäre großartig, wenn ich die physische Festplatte als ro im Host-Betriebssystem einbinden und die Daten auf ein externes USB-Laufwerk kopieren könnte. Der Host-Server verfügt nur über einen USB-Controller, daher ist PCI-Passthrough keine Option.

— Zhuoyun Wei,

Antworten:

Nein. Auf dem schreibgeschützten Client werden aufgrund der Zwischenspeicherung keine konsistenten Ergebnisse angezeigt. Es ist definitiv nicht dafür ausgelegt. Es ist zu erwarten, dass E / A-Fehler an Anwendungen zurückgegeben werden. Es gibt wahrscheinlich immer noch eine Reihe von Fehlern im Code, die einen Kernelabsturz oder eine Beschädigung des von einem Prozess verwendeten Speichers verursachen können.

Am wichtigsten ist jedoch, dass ext4 das Journal auch auf schreibgeschützten Reitern wiedergibt. Daher schreibt ein schreibgeschützter Mount weiterhin auf das zugrunde liegende Blockgerät. Es wäre unsicher, selbst wenn beide Reittiere schreibgeschützt wären :).

— sourcejedi
quelle

Wie Sie bereits sagten, garantiert das schreibgeschützte Aktivieren nicht, dass das Dateisystem unberührt bleibt. Wenn Sie immer noch für „erzieherischen“ Zweck versuchen wollen , ohne Risiken einzugehen, sollten Sie Ihr Set - Gerät nur lesbar: blockdev --setro /dev/sda1.

— Totor

Das sind interessante Informationen zum ext4-Mount. Ich nehme an, man könnte dieses Problem vermeiden, indem man ext2 schreibgeschütztes Mounten erzwingt.

— Bananguin

Ich fand diesen Code - Schnipsel , die ich ein Nur - Lese-Block - Gerät in einer VM montieren lassen: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/...

— isaaclw

Dies vermeidet Datenbeschädigungen, wird aber wahrscheinlich nicht das sein, was Sie tun möchten. Ich habe noch nie Probleme beim Mounten des Volumes mit Lesezugriff auf einem anderen Knoten bemerkt. Auch wenn auf dem ro-Knoten normalerweise etwas nicht passt, das nur einen "unerwarteten freien Inode" auslöst, führen Sie bitte e2fsck oder ähnliches in / var / log / messages aus. Wenn etwas an einem nicht-kritischen Dateisystem ("/ opt / mySpecialmount") furchtbar unerwartet ist, hängt Linux das Volume normalerweise nur mit Lesezugriff ein (was hey, wir sind bereits da). Wenn Sie sich große Sorgen darüber machen, welche Auswirkungen das Caching hat, können Sie versuchen, eine Art drop_caches / vfs_cache_pressure-Regime in Gang zu setzen.

Um zu vermeiden, dass das Journal erneut abgespielt wird, fügen Sie "noload" zu den Mount-Argumenten hinzu.

Trotzdem ist es wahrscheinlich, dass NFS oder smbfs das Problem lösen und für etwas mehr Parallelität ausgelegt sind als ext3 / 4 wäre. Wenn Sie Leistung benötigen, können Sie in ein gruppiertes Dateisystem schauen (etwas mehr Verwaltungsaufwand, aber es ist vorhanden, wenn Leistung wirklich etwas ist, das Sie benötigen).

— Bratchley
quelle

" Dadurch werden Datenbeschädigungen vermieden": Möglicherweise wird die Antwort von sourcejedi und mein Kommentar nicht angezeigt .

— Totor

"Das Überspringen der Journalwiedergabe führt dazu, dass das Dateisystem Inkonsistenzen enthält, die zu einer beliebigen Anzahl von Problemen führen können" - man mount. Ich kann mir vorstellen, dass es Anwendungen gibt, die inkonsistente Daten in ihren Dateien erkennen und / oder tolerieren, aber Sie haben bisher keinen solchen Vorbehalt erwähnt :).

— Sourcejedi

@sourcejedi Das sagen sie, weil sie versuchen, den Leuten die Risiken einer effektiven Außerbetriebnahme des Journals zu erklären. Dies ist in Ordnung, da davon ausgegangen wird, dass der andere Knoten die Journalarbeit für den anderen Knoten erledigt. Wir versuchen nur, doppelte Arbeit zu vermeiden. Wir machen das auf einem unserer Entwicklungsserver (nicht meine Wahl, ich hätte NFS gemacht) und haben das Ding fast ein Jahr ohne irgendwelche Probleme ohne einen drop_caches gemountet. Wir haben beide erwähnt, dass nicht veraltete FS-Cache-Einträge alte Daten rendern können, aber letztendlich muss der Administrator entscheiden, ob dies funktioniert.

— Bratchley

Ich werde nicht versuchen, die ganze Unrichtigkeit in dem obigen Kommentar aufzuzählen. Als ein Datenpunkt geht es jedoch nicht nur um veraltete Dateidaten im VFS-Cache. ext4 wird auch Caches der internen Datenstrukturen des Dateisystems ("Metadaten") haben. Sie könnten am Ende Daten aus einer gelöschten Datei lesen, die anschließend von einer neuen Datei überschrieben wurde. Das ist die Art von Einschränkung, über die Sie im Voraus Bescheid wissen möchten, auch wenn dies nur selten vorkommt.

— Sourcejedi

Wenn Sie auf Ihren Kommentar zurückblicken, denken Sie, dass Sie möglicherweise versuchen, auf Block-Level-Caching zu verweisen, das Caching von Block-Device-I / O im Speicher. In diesem Fall ist es nicht , dass das Caching tritt in den Metadaten selbst, es Caching von Metadaten selbst. Es ist auch außerhalb von Dateisystemtreibern vorhanden, sodass ext4 / btrfs / etc nicht verwaltet werden kann.

— Bratchley