Le même disque ext4 peut-il être monté à partir de deux hôtes, un en lecture seule?

Je sais que monter le même disque avec un système de fichiers ext4 à partir de deux serveurs différents (c'est un vloume iSCSI) corrompra probablement les données sur le disque. Ma question est la suivante: cela fera - t-il une différence si l'un des serveurs monte le disque en lecture seule tandis que l'autre le monte en lecture-écriture?

Je sais que OCFS2 ou les goûts pourraient être utilisés pour cela et que je pourrais exporter le disque avec NFS pour être accessible à l'autre serveur, mais je voudrais savoir si la configuration que je propose fonctionnera.

linux mount ext4

— Fernando
source

Cela ne pourrait fonctionner que si les deux sont montés en lecture seule (et j'entends par là une vraie lecture seule qui n'écrit pas). Dès qu'un côté monte en lecture-écriture, l'autre côté (monté en lecture seule) ne s'attend pas à des modifications de l'autre côté (monté en lecture-écriture) et lit donc les données corrompues. Vous avez besoin d'un système de fichiers compatible avec les clusters ou d'un serveur unique qui expose un système de fichiers réseau à l'autre.

— frostschutz

@frostschutz Oui, les deux ro fonctionneront mais pas sans astuces puisque le ro-mount d'ext4 écrit sur le disque réel (a besoin d'une ro-loop et d'un overlayfs chacun).

— Ned64

Je vais partager un cas d'utilisation ici: un serveur physique et un serveur virtuel partagent un disque physique avec une passe-disque. Le serveur virtuel monte le disque en tant que rw. Je voudrais copier une grande quantité de données depuis le disque mais le réseau est trop lent. Ce serait formidable si je pouvais monter le disque physique en tant que ro dans le système d'exploitation hôte et copier les données sur un lecteur USB externe. Le serveur hôte ne possède qu'un seul contrôleur USB, donc le passthrough PCI n'est pas une option.

— Zhuoyun Wei

Réponses:

Non. Cela ne donnera pas de résultats cohérents sur le client en lecture seule, en raison de la mise en cache. Ce n'est certainement pas conçu pour ça. Vous pouvez vous attendre à voir des erreurs d'E / S renvoyées aux applications. Il y a probablement encore un certain nombre d'erreurs dans le code, ce qui pourrait provoquer un crash du noyau ou une mémoire corrompue utilisée par n'importe quel processus.

Mais surtout, ext4 relit le journal même sur des montages en lecture seule. Ainsi, un montage en lecture seule continuera d'écrire sur le périphérique de bloc sous-jacent. Ce serait dangereux même si les deux supports étaient en lecture seule :).

— sourcejedi
source

Comme vous le dites, le montage en lecture seule ne garantit pas que le système de fichiers sera intact. Si vous voulez continuer à essayer pour but « éducatif » sans prendre de risques, vous devez configurer votre appareil en lecture seule: blockdev --setro /dev/sda1.

— Totor

Ce sont des informations intéressantes sur le montage ext4. Je suppose que l'on pourrait éviter ce problème en forçant le montage en lecture seule ext2?

— Bananguin

J'ai trouvé ce bout de code qui laissez - moi monter un périphérique bloc en lecture seule dans une machine virtuelle: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/...

— isaaclw

Cela évitera la corruption des données, mais ne sera probablement pas ce que vous voulez faire. Je n'ai jamais remarqué de problème lors du montage du volume en lecture seule sur un autre nœud. Même si quelque chose ne correspond pas sur le nœud ro, cela ne fait que lancer un "inode libre inattendu, veuillez exécuter e2fsck" ou similaire dans / var / log / messages. Si quelque chose est terriblement inattendu à propos d'un système de fichiers non critique ("/ opt / mySpecialmount"), Linux montera généralement le volume en lecture seule (ce qui, nous y sommes déjà). Si vous êtes très inquiet de l'effet de la mise en cache, vous pouvez essayer de mettre en place une sorte de régime drop_caches / vfs_cache_pressure.

Pour éviter de rejouer le journal, ajoutez "noload" aux arguments de montage, faites-le en même temps que errors = remount-ro (juste pour pécher par excès de prudence).

Cela dit, il y a de fortes chances que si vous êtes prêt à le monter en lecture seule, c'est probablement juste comme référence pour l'autre nœud, auquel cas NFS ou smbfs résoudraient le problème et est conçu pour un peu plus de concurrence que ext3 / 4 serait. Si vous avez besoin de performances, vous pouvez examiner un système de fichiers en cluster (un peu plus de surcharge administrative, mais c'est là si les performances sont vraiment quelque chose dont vous avez besoin).

— Bratchley
source

" Cela évitera la corruption des données ": il se peut que non, voir la réponse de sourcejedi et mon commentaire .

— Totor

"sauter la relecture du journal entraînera le système de fichiers contenant des incohérences qui peuvent conduire à un certain nombre de problèmes" - man mount. Je peux imaginer qu'il existe des applications qui détecteraient et / ou tolèreraient des données incohérentes dans leurs fichiers, mais vous n'avez mentionné aucune mise en garde à ce jour :).

— sourcejedi

@sourcejedi Ils disent cela parce qu'ils essaient de dire aux gens les risques d'une mise à l'écart efficace du journal. C'est bien, car l'hypothèse est que l'autre nœud effectuera le travail de journal pour l'autre nœud, nous essayons simplement d'éviter le double travail. Nous le faisons sur l'un de nos serveurs de développement (pas mon choix, j'aurais fait NFS) et nous avons monté cette chose sans même un drop_caches pendant près d'un an sans aucun problème. Nous avons tous deux mentionné que les entrées de cache FS non périmées peuvent restituer d'anciennes données, mais c'est finalement à l'administrateur de décider si cela est réalisable.

— Bratchley

Je ne vais pas essayer d'énumérer tout le tort dans le commentaire ci-dessus. Mais en tant que point de données, il ne s'agit pas seulement de données de fichier périmées dans le cache VFS. ext4 aura également des caches des structures de données internes du système de fichiers ("métadonnées"). Vous pourriez finir par lire les données d'un fichier supprimé, qui a ensuite été remplacé par un nouveau fichier. C'est le genre de mise en garde que vous voulez vraiment savoir à l'avance, même si cela ne se produit que rarement.

— sourcejedi

En repensant à votre commentaire, je pense que vous essayez peut-être de faire référence à la mise en cache au niveau du bloc, qui est la mise en cache des E / S de périphérique de bloc en mémoire. Dans ce cas, il ne cache qui se produit dans les métadonnées lui - même, il est la mise en cache DES métadonnées lui - même. Il existe également en dehors de tout pilote de système de fichiers, donc ext4 / btrfs / etc n'en a aucune gestion.

— Bratchley