Dapatkah disk ext4 yang sama dipasang dari dua host, satu dapat dibaca?

Saya tahu bahwa memasang disk yang sama dengan sistem file ext4 dari dua server yang berbeda (ini merupakan vloume iSCSI) kemungkinan akan merusak data pada disk. Pertanyaan saya adalah apakah akan ada bedanya jika salah satu server me-mount disk read-only sedangkan yang lain me-mount read-write?

Saya tahu OCFS2 atau sejenisnya dapat digunakan untuk ini dan saya dapat mengekspor disk dengan NFS agar dapat diakses ke server lain, tetapi saya ingin tahu apakah pengaturan yang saya usulkan akan bekerja.

linux mount ext4

— Fernando
sumber

Itu bisa bekerja hanya jika keduanya dipasang read-only (dan maksud saya benar read-only yang tidak menulis). Segera setelah satu sisi me-mount read-write, sisi lainnya (mount read-only) tidak mengharapkan perubahan dari sisi lain (mount read-write), dan karenanya membaca data yang korup. Yang Anda butuhkan adalah filesystem sadar-cluster, atau satu server yang mengekspos sistem file jaringan yang lain.

— frostschutz

@ frostschutz Ya, kedua ro akan bekerja tetapi tidak tanpa trik karena ro-mount ext4 menulis ke disk sebenarnya (masing-masing membutuhkan ro-loop dan overlay).

— Ned64

Saya akan membagikan use case di sini: server fisik dan server virtual berbagi disk fisik dengan disk pass-through. Server virtual memasang disk sebagai rw. Saya ingin menyalin sejumlah besar data dari disk tetapi jaringannya terlalu lambat. Akan lebih bagus jika saya bisa memasang disk fisik seperti ro di OS host dan menyalin data ke drive USB eksternal. Server host hanya memiliki satu pengontrol USB sehingga PCI-passthrough bukanlah suatu pilihan.

— Zhuoyun Wei

Jawaban:

Tidak. Itu tidak akan memberikan hasil yang konsisten pada klien baca-saja, karena caching. Jelas tidak dirancang untuk itu. Anda bisa berharap melihat kesalahan IO dikembalikan ke aplikasi. Mungkin masih ada beberapa kelalaian dalam kode, yang dapat menyebabkan kernel crash atau memori rusak yang digunakan oleh proses apa pun.

Tapi yang paling penting, ext4 memutar ulang jurnal bahkan di tunggangan readonly. Jadi mount readonly masih akan menulis ke perangkat blok yang mendasarinya. Akan tidak aman bahkan jika kedua mount dibaca hanya :).

— sourcejedi
sumber

Seperti yang Anda katakan, me-mount readonly tidak menjamin bahwa sistem file tidak akan tersentuh. Jika Anda masih ingin mencoba untuk "pendidikan" tujuan tanpa mengambil risiko, Anda harus mengatur Anda perangkat dibaca: blockdev --setro /dev/sda1.

— Totor

Informasi menarik tentang mount ext4. Saya kira orang bisa menghindari masalah ini dengan memaksa mount read-only ext2?

— Bananguin

Saya menemukan potongan kode ini yang memungkinkan saya memasang perangkat blok read-only di VM: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/…

— isaaclw

Ini akan menghindari kerusakan data, tetapi mungkin tidak akan seperti yang Anda inginkan. Saya tidak pernah melihat ada masalah pemasangan volume read-only pada node lain. Bahkan jika sesuatu tidak cocok pada ro node biasanya yang hanya melempar "inode gratis yang tak terduga, silakan jalankan e2fsck" atau sejenisnya ke / var / log / messages. Jika ada sesuatu yang sangat tidak terduga tentang sistem file yang tidak kritis ("/ opt / mySpecialmount") biasanya Linux hanya akan me-mount volume read-only (yang, hei, kita sudah ada di sana). Jika Anda sangat khawatir tentang efek caching yang terjadi, Anda bisa mencoba menjalankan semacam drop_caches / vfs_cache_pressure rezim.

Untuk menghindari pemutaran ulang jurnal, tambahkan "noload" ke mount args, lakukan itu bersama dengan error = remount-ro (hanya untuk berbuat salah di sisi hati-hati).

Yang mengatakan, kemungkinannya adalah jika Anda OK dengan me-mount itu read-only, itu mungkin hanya sebagai referensi untuk node lain, dalam hal ini NFS atau smbfs akan menyelesaikan masalah dan dirancang untuk konkurensi lebih sedikit daripada ext3 / 4 akan. Jika Anda memerlukan kinerja maka Anda dapat melihat ke sistem file yang dikelompokkan (sedikit lebih banyak biaya administrasi, tetapi ada jika kinerja benar-benar sesuatu yang Anda butuhkan).

— Bratchley
sumber

" Ini akan menghindari kerusakan data ": mungkin tidak, lihat jawaban sourcejedi dan komentar saya .

— Totor

"Melewati pemutaran ulang jurnal akan mengarah ke sistem file yang berisi inkonsistensi yang dapat menyebabkan sejumlah masalah" - man mount. Saya bisa membayangkan ada aplikasi yang akan mendeteksi dan / atau mentolerir data yang tidak konsisten dalam file mereka, tetapi Anda belum menyebutkan peringatan sejauh ini :).

— sourcejedi

@sourcejedi Mereka mengatakan itu karena mereka mencoba memberi tahu orang-orang tentang risiko tersingkirnya jurnal secara efektif. Ini baik-baik saja, karena asumsinya adalah bahwa simpul lain akan melakukan pekerjaan jurnal untuk simpul lain, kami hanya berusaha untuk menghindari kerja ganda. Kami melakukan ini di salah satu server pengembangan kami (bukan pilihan saya, saya akan melakukan NFS) dan telah menginstalnya tanpa drop_caches selama hampir satu tahun tanpa masalah sama sekali. Kami berdua menyebutkan bahwa entri cache FS yang tidak basi dapat membuat data lama, tetapi pada akhirnya tergantung pada admin untuk memutuskan apakah ini bisa diterapkan.

— Bratchley

Saya tidak akan mencoba untuk menghitung semua kesalahan dalam komentar di atas. Tetapi sebagai satu titik data, ini bukan hanya tentang data file basi dalam cache VFS. ext4 akan memiliki cache dari struktur data internal filesystem ("metadata") juga. Anda dapat membaca data dari file yang dihapus, yang kemudian ditimpa oleh file baru. Itu semacam peringatan yang benar-benar ingin Anda ketahui sebelumnya, meskipun itu hanya akan jarang terjadi.

— sourcejedi

Melihat kembali komentar Anda, saya pikir Anda mungkin mencoba merujuk ke caching level-blok, yang merupakan caching perangkat I / O blok di memori. Dalam hal ini, itu bukan caching yang terjadi dalam metadata itu sendiri, itu caching OF metadata itu sendiri. Itu juga ada di luar driver filesystem sehingga ext4 / btrfs / etc tidak memiliki manajemen itu.

— Bratchley