Чи можна один і той же диск ext4 монтувати з двох хостів, один лише заново?

Я знаю, що встановлення одного і того ж диска з файловою системою ext4 з двох різних серверів (це вкладка iSCSI), ймовірно, пошкодить дані на диску. Моє запитання, чи матиме це значення, якщо один з серверів змонтує диск лише для читання, а інший змонтує його для читання-запису?

Я знаю, що OCFS2 або подібні можуть бути використані для цього і що я можу експортувати диск з NFS, щоб він був доступний на інший сервер, але я хотів би знати, чи запрацює запропонована нами установка.

linux mount ext4

— Фернандо
джерело

Він може працювати лише в тому випадку, якщо обидва встановлені лише для читання (і маю на увазі справжнє лише для читання, яке не пише). Як тільки одна сторона змонтує читання-запис, інша сторона (змонтована лише для читання) не очікує змін з іншого боку (змонтована читання-запис), і, таким чином, вона зчитує пошкоджені дані. Вам потрібна файлова система, відома кластеру, або один сервер, який відкриває мережеву файлову систему іншому.

— frostschutz

@frostschutz Так, обидва ro будуть працювати, але не без хитрощів, оскільки ro-mount ext4 записує на фактичний диск (потрібен цикл ro та накладення кожного).

— Ned64

Тут я поділюсь випадком використання: фізичний та віртуальний сервери діляться фізичним диском з проходом диска. Віртуальний сервер монтує диск як rw. Я хотів би скопіювати велику кількість даних з диска, але мережа занадто повільна. Було б чудово, якби я міг змонтувати фізичний диск як ro в хост-операційній системі та скопіювати дані на зовнішній накопичувач USB. Хост-сервер має лише один USB-контролер, тому проходження PCI - це не варіант.

— Чжуюн Вей

Відповіді:

Ні. Це не дасть послідовних результатів для клієнта, доступного лише для читання, через кешування. Це точно не призначено для цього. Можна очікувати, що помилки IO повернуться до програм. Напевно, все ще є деяка кількість оглядів у коді, які можуть спричинити збій ядра або пошкодити пам'ять, яка використовується будь-яким процесом.

Але найголовніше, що ext4 відтворює журнал навіть на монтажах, які читаються лише зараз. Таким чином, кріплення, готове лише заново, записуватиме в базовий блок пристрою. Це було б небезпечно, навіть якби обидва кріплення були прочитані тільки :).

— sourcejedi
джерело

Як ви кажете, монтаж лише для читання не гарантує, що файлова система буде недоторканою. Якщо ви все ще хочете спробувати «освітню» мета без урахування ризиків, ви повинні встановити пристрій для читання: blockdev --setro /dev/sda1.

— Тотор

Цікава інформація про кріплення ext4. Я припускаю, що можна було б уникнути цієї проблеми, змусивши монтувати ext2 лише для читання?

— Bananguin

Я знайшов цей фрагмент коду , який дозволить мені монтувати блоковий пристрій тільки для читання в VM: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14 / ...

— isaaclw

Це дозволить уникнути пошкодження даних, але, ймовірно, не буде тим, що ви хочете робити. Я ніколи не помічав жодних проблем із встановленням тома лише для читання на іншому вузлі. Навіть якщо на вузлі ro щось не відповідає, що просто кидає "несподіваний безкоштовний inode", запустіть e2fsck "тощо" у / var / log / messages. Якщо у некритичній файловій системі ("/ opt / mySpecialmount") щось страшно несподівано, зазвичай Linux просто змонтує обсяг лише для читання (що ж, ми вже є). Якщо ви дуже переживаєте, який ефект кешування має, ви можете спробувати перейти до режиму drop_caches / vfs_cache_pressure.

Щоб уникнути відтворення журналу, додайте "noload" до аргументів монтування, зробіть це разом з помилками = remount-ro (просто щоб помилитися з боку обережності).

Це означає, що, якщо ви все в порядку, встановивши його лише для читання, це, мабуть, просто як посилання на інший вузол, і в такому випадку NFS або smbfs вирішили б проблему і розраховані на трохи більше одночасності, ніж ext3 / 4 було б. Якщо вам потрібна продуктивність, ви можете заглянути в кластерну файлову систему (трохи більше адміністративних накладних витрат, але це там, якщо продуктивність дійсно потрібна).

— Братчлі
джерело

" Це дозволить уникнути корупції даних ": це може бути не так, див. Відповідь sourcejedi та мій коментар .

— Тотор

"пропуск повтору журналу призведе до того, що файлова система містить невідповідності, які можуть призвести до будь-якої кількості проблем" - man mount. Я можу собі уявити, що є програми, які б виявляли та / або переносили непослідовні дані у своїх файлах, але ви ще не згадували жодного такого застереження :).

— sourcejedi

@sourcejedi Вони говорять, що тому, що вони намагаються розповісти людям про ризики ефективного переходу до журналу. Це добре, тому що припущення полягає в тому, що інший вузол буде робити журнал для іншого вузла, ми просто намагаємося уникати подвійної роботи. Ми робимо це на одному з наших серверів розробки (не на мій вибір, я б робив NFS) і встановлювали цю річ без навіть drop_caches протягом року майже без проблем. Ми обоє згадували, що нестарелі записи кешу FS можуть надавати старі дані, але в остаточному підсумку адміністратор повинен вирішити, чи це можливо.

— Братчлі

Я не збираюся намагатися перерахувати всю неправильність у наведеному вище коментарі. Але, як один із даних, мова йде не лише про застарілі файлові дані в кеші VFS. У ext4 також будуть кеші внутрішніх структур файлової системи ("метадані"). Ви можете закінчити читання даних із видаленого файлу, який згодом був перезаписаний новим файлом. Це такий застереження, про який ви справді хочете знати заздалегідь, навіть якщо це станеться нечасто.

— sourcejedi

Озираючись на ваш коментар, я думаю, що ви, можливо, намагаєтеся посилатися на кешування рівня керування, яке є кешування блоку вводу / виводу пристрою в пам'яті. У цьому випадку, це не кешування , що відбувається в самій, це кешування метаданих OF самого метаданих. Він також існує поза будь-якими драйверами файлової системи, тому ext4 / btrfs / тощо не мають управління ним.

— Братчлі