Можно ли подключить один и тот же диск ext4 с двух хостов, один только для чтения?

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

Я знаю, что для этого можно использовать OCFS2 или что-то подобное, и я мог бы экспортировать диск с NFS, чтобы он был доступен для другого сервера, но я хотел бы знать, сработает ли предложенная мной установка.

linux mount ext4

— Фернандо
источник

Это может работать, только если оба смонтированы только для чтения (и под этим я подразумеваю истинное только для чтения, которое не пишет). Как только одна сторона монтирует чтение-запись, другая сторона (монтируется только для чтения) не ожидает изменений другой стороной (монтируется чтение-запись) и, таким образом, считывает поврежденные данные. Вам нужна файловая система с поддержкой кластеров или один сервер, который предоставляет сетевую файловую систему другому.

— frostschutz

@frostschutz Да, оба ro будут работать, но не без хитростей, так как ro-mount ext4 выполняет запись на реальный диск (требуется ro-loop и overlayfs каждый).

— Нед64

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

— Чжуоюнь Вэй

Ответы:

Нет. Это не даст согласованных результатов на клиенте только для чтения из-за кэширования. Это определенно не предназначено для этого. Вы можете ожидать появления ошибок ввода-вывода в приложениях. Вероятно, в коде все еще есть некоторые упущения, которые могут привести к сбою ядра или повреждению памяти, используемой любым процессом.

Но самое главное, 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, обычно это просто вызывает «неожиданный свободный инод, пожалуйста, запустите e2fsck» или тому подобное в / var / log / messages. Если что-то ужасно неожиданно для некритической файловой системы ("/ opt / mySpecialmount"), обычно Linux просто монтирует том только для чтения (что, эй, мы уже там). Если вас очень волнует, как кеширует эффект, вы можете попробовать запустить какой-нибудь режим drop_caches / vfs_cache_pressure.

Чтобы избежать повторного воспроизведения журнала, добавьте «noload» к аргументам монтирования, сделайте это вместе с ошибками = remount-ro (просто для того, чтобы ошибиться из-за осторожности).

Тем не менее, есть вероятность, что если вы в порядке с монтированием только для чтения, это, вероятно, просто как ссылка на другой узел, и в этом случае NFS или smbfs решит проблему и рассчитан на немного больший параллелизм, чем ext3 / 4 будет. Если вам нужна производительность, то вы можете изучить кластерную файловую систему (немного больше административных затрат, но она есть, если производительность действительно нужна).

— Bratchley
источник

« Это позволит избежать повреждения данных »: это может не произойти, см. Ответ Sourcejedi и мой комментарий .

— Тотор

«Пропуск воспроизведения журнала приведет к файловой системе, содержащей несоответствия, которые могут привести к любому количеству проблем» - man mount. Я могу себе представить, что есть приложения, которые обнаруживают и / или допускают несогласованность данных в своих файлах, но вы еще не упомянули ни одного подобного предостережения :).

— sourcejedi

@sourcejedi Они говорят, что, потому что они пытаются рассказать людям о рисках эффективного отстранения журнала. Это нормально, поскольку предполагается, что другой узел будет выполнять работу с журналом для другого узла, мы просто пытаемся избежать двойной работы. Мы делаем это на одном из наших серверов разработки (не мой выбор, я бы сделал NFS) и смонтировали эту штуку без даже drop_caches в течение почти года без каких-либо проблем. Мы оба упоминали, что не устаревшие записи кэша ФС могут отображать старые данные, но в конечном итоге администратор должен решить, является ли это работоспособным.

— Братчли

Я не собираюсь пытаться перечислить всю неправильность в вышеприведенном комментарии. Но как одна точка данных, речь идет не только об устаревших данных файла в кеше VFS. ext4 также будет иметь кэш внутренних структур данных файловой системы («метаданных»). Вы можете прочитать данные из удаленного файла, который впоследствии был перезаписан новым файлом. Это тот тип предостережения, о котором вы действительно хотите знать заранее, даже если это случится нечасто.

— sourcejedi

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

— Братчли