Lo stesso disco ext4 può essere montato da due host, uno di sola lettura?

So che montare lo stesso disco con un filesystem ext4 da due server diversi (è un vloume iSCSI) probabilmente danneggerà i dati sul disco. La mia domanda è : farà una differenza se uno dei server monta il disco in sola lettura mentre l'altro monta in lettura-scrittura?

So che OCFS2 o simili potrebbero essere usati per questo e che potrei esportare il disco con NFS per renderlo accessibile all'altro server, ma vorrei sapere se l'installazione che propongo funzionerà.

linux mount ext4

— Fernando
fonte

Potrebbe funzionare solo se entrambi sono montati in sola lettura (e con questo intendo la sola lettura che non scrive). Non appena un lato monta la lettura-scrittura, l'altro lato (montato in sola lettura) non si aspetta modifiche dall'altro lato (montato in lettura-scrittura) e quindi legge i dati corrotti. Ciò di cui hai bisogno è un filesystem sensibile al cluster o un singolo server che esponga un filesystem di rete all'altro.

— frostschutz,

@frostschutz Sì, entrambi i ro funzioneranno ma non senza trucchi poiché il ro-mount di ext4 scrive sul disco reale (necessita di un ro-loop e di un overlayfs ciascuno).

— Ned64,

Condividerò qui un caso d'uso: un server fisico e un server virtuale condividono un disco fisico con pass-through del disco. Il server virtuale sta montando il disco come rw. Vorrei copiare una grande quantità di dati dal disco ma la rete è troppo lenta. Sarebbe bello se potessi montare il disco fisico come ro nel sistema operativo host e copiare i dati su un'unità USB esterna. Il server host ha un solo controller USB, quindi il passthrough PCI non è un'opzione.

— Zhuoyun Wei,

Risposte:

No. Non fornirà risultati coerenti sul client di sola lettura, a causa della memorizzazione nella cache. Non è assolutamente progettato per questo. Potresti aspettarti di vedere gli errori IO restituiti alle applicazioni. Probabilmente c'è ancora un certo numero di sviste nel codice, che potrebbero causare un arresto anomalo del kernel o la memoria corrotta utilizzata da qualsiasi processo.

Ma soprattutto, ext4 riproduce il diario anche su supporti di sola lettura. Quindi un mount di sola lettura scriverà comunque sul dispositivo a blocchi sottostante. Sarebbe pericoloso anche se entrambi i supporti fossero di sola lettura :).

— sourcejedi
fonte

Come dici tu, il montaggio in sola lettura non garantisce che il filesystem rimarrà intatto. Se si vuole ancora provare a scopo "educativo" senza prendere rischi, è necessario impostare il dispositivo di sola lettura: blockdev --setro /dev/sda1.

— Totor,

Grazie alle interessanti informazioni sul mount ext4. Suppongo che uno potrebbe evitare questo problema forzando mount di sola lettura ext2?

— Bananguin,

Ho trovato questo frammento di codice che mi ha permesso di montare un dispositivo a blocchi di sola lettura in una VM: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/…

— isaaclw

Ciò eviterà il danneggiamento dei dati, ma probabilmente non sarà quello che vuoi fare. Non ho mai notato problemi di montaggio del volume di sola lettura su un altro nodo. Anche se qualcosa non coincide sul nodo ro di solito genera solo un "inode gratuito inatteso, esegui e2fsck" o simili in / var / log / messages. Se qualcosa è terribilmente inatteso in un filesystem non critico ("/ opt / mySpecialmount"), di solito Linux monterà il volume di sola lettura (che, ehi, siamo già lì). Se sei molto preoccupato per l'effetto della memorizzazione nella cache, puoi provare a far funzionare una sorta di regime drop_caches / vfs_cache_pressure.

Per evitare la ripetizione del journal, aggiungi "noload" agli argomenti mount, fallo insieme a errors = Remunt-Ro (solo per sbagliare sul versante della cautela).

Detto questo, è probabile che se stai bene montandolo in sola lettura, probabilmente è solo un riferimento per l'altro nodo, nel qual caso NFS o smbfs risolverebbero il problema ed è progettato per un po 'più di concorrenza di ext3 / 4 sarebbe. Se hai bisogno di prestazioni, allora potresti guardare in un filesystem in cluster (un po 'più di gestione amministrativa, ma è lì se le prestazioni sono davvero qualcosa di cui hai bisogno).

— Bratchley
fonte

" Questo eviterà la corruzione dei dati ": potrebbe non esserlo, vedi la risposta di sourcejedi e il mio commento .

— Totor,

"saltare la riproduzione del journal porterà al filesystem che contiene incoerenze che possono portare a un numero qualsiasi di problemi" - man mount. Posso immaginare che ci siano applicazioni in grado di rilevare e / o tollerare dati incoerenti nei loro file, ma finora non hai menzionato alcun avvertimento :).

— Fontejedi

@sourcejedi Lo dicono perché stanno cercando di dire alla gente i rischi di mettere effettivamente fuori gioco il diario. Questo va bene, perché il presupposto è che l'altro nodo eseguirà il lavoro journal per l'altro nodo, stiamo solo cercando di evitare il doppio lavoro. Lo facciamo su uno dei nostri server di sviluppo (non la mia scelta, avrei fatto NFS) e abbiamo fatto montare quella cosa senza nemmeno un drop_caches per quasi un anno senza alcun problema. Abbiamo entrambi menzionato che le voci della cache FS non obsolete possono eseguire il rendering di vecchi dati, ma alla fine spetta all'amministratore decidere se questo è fattibile.

— Bratchley,

Non tenterò di elencare tutte le torto nel commento sopra. Ma come punto dati, non si tratta solo di dati di file non aggiornati nella cache VFS. ext4 avrà anche cache delle strutture di dati interne del filesystem ("metadati"). Potresti finire per leggere i dati da un file eliminato, che è stato successivamente sovrascritto da un nuovo file. Questo è il tipo di avvertimento che vuoi davvero conoscere in anticipo, anche se succederà raramente.

— Fontejedi

Ripensando al tuo commento, penso che potresti provare a fare riferimento alla memorizzazione nella cache a livello di blocco, che è la memorizzazione nella cache degli I / O del dispositivo a blocchi. In tal caso, non è caching che si verifica nei metadati sé, di caching DI metadati stessa. Esiste anche al di fuori di qualsiasi driver di file system, quindi ext4 / btrfs / etc non ne ha alcuna gestione.

— Bratchley,