Ну, це дійсно залежить від того, наскільки ви хочете басейну бути лише для читання. І ні, це не жарт.
По-перше, трохи термінології: в ZFS ви імпортуєте пул і необов'язково монтуєте в ньому (будь-які) файлові системи. Ви можете імпортувати пул, не монтуючи жодної файлової системи, перейшовши -Nдо zpool importта потім змонтуйте будь-яку потрібну файлову систему за допомогою zfs mount. (Це цілком вірний сценарій, якщо, наприклад, ви хочете отримати доступ до лише однієї файлової системи з багатьох, або якщо ви хочете зробити щось, що нагадує офлайн-скраб пулу.)
ZFS не є великим шанувальником дійсного доступу лише для читання. Наприклад, якщо ZFS виявить помилку, яку він може виправити, я вважаю, що вона виправить помилку і запише відремонтовані дані на диск, навіть якщо ви імпортували пул як лише для читання. Я розумію, що у пакеті ZFS "лише для читання" стосується лише видимого користувачем стану пулу та його наборів даних. Якщо, з іншого боку, ви зробите двійкову копію диска у файл (або набір файлів), зробіть ці файли справді лише для читання та спробуйте імпортувати пул звідти, ZFS не зможе імпортувати імпорт басейн взагалі, як би ви не старалися. Якщо ви зробите файли для запису, вони будуть добре працювати. (Я насправді пробував це лише кілька тижнів тому, хоч і використовував zvol, і ZFS жорстоко відмовлявсяімпортувати пул. Коли я встановлюю zvol для читання / запису замість лише для читання, пул імпортує чудово.) Інші файлові системи, як-от (на Linux) ext4 та, ймовірно, інші вирішують цю ситуацію дещо витончено, але ZFS баксує.
Якщо вам не пощастило і у вас не встановлена оперативна пам’ять ECC в системі, куди ви імпортуєте пул, спроба ZFS виправити будь-які помилки, з якими вона стикається, може насправді погіршити ситуацію , хоча думки відрізняються від того, чи є це насправді реальним ризиком на практиці. Особисто я вважаю, що будь-які дані, які мені достатньо цікаві для захисту за допомогою ZFS та знімків, надмірності та резервного копіювання на рівні пам’яті, і що не заслуговує на захист, пропонований оперативною пам’яттю ECC, але багато ПК не мають оперативної пам’яті ECC.
Отже, ви можете імпортувати пул у режимі лише для читання, із певним альтернативним коренем, щоб він не наступав на будь-які інші пальці ніг, але потрібно пам’ятати, що це не обов’язково по - справжньому лише для читання у криміналістичному сенсі. (Це, однак, забезпечить, щоб ви випадково нічого не змінили в пулі.) Щоб здійснити імпорт лише для читання, вважаючи, що пул названий tankі що вузли (-и) пристрою є / доступні в /dev, використовувати команду типу:
# zpool import tank -d /dev -o readonly=on -R /mnt/someplace
Тут буде шукати /devвсе, що містить пул ZFS з назвою tank, імпортує його, тимчасово встановивши властивість пулу readonlyна on(що означає, що всі записи, ініційовані користувачем, будуть відхилені) та тимчасово встановити його altrootвластивість /mnt/someplace. (Ці значення властивості є "тимчасовими", оскільки вони не зберігаються на диску (дисках) як поточні значення властивостей, тому якщо ви експортуєте та повторно імпортуєте пул без них, ці значення повернуться до нормальних показників. Вони можуть можливо, буде записано в історію пулу, яку після імпортування пулу ви можете переглянутиzpool history tank якщо ви так схильні.) Після імпорту пулу ви побачите свої файли під / mnt / someplace і матимете нормальний доступ до них лише для читання, включаючи будь-які знімки, які вже зроблені на наборах даних у пулі.
З огляду на ваш приклад, я підозрюю, що ви будете використовувати щось за принципом:
# zpool import zroot02 -d /dev -o readonly=on -R /mnt/my-fun-mountpoint
Коли ви закінчите, не забудьте чисто експортувати пул:
# zpool export tank
чи, можливо,
# zpool export zroot02
Це дозволить відключити всі файлові системи та інші набори даних у пулі, змити всі буфери (настільки, наскільки в першу чергу потребує промивання), позначити пул як не імпортований на всіх складових пристроях та виконувати будь-які інші необхідні завдання з обслуговування, щоб забезпечити що пул можна безпечно перемістити до іншої системи та імпортувати туди пізніше.