Тот же ext4 диск может быть смонтирован от двух хостов, одного только для чтения?
Ваш ЦП является x86_64 (Intel Core i5), таким образом, любой может использоваться; это - Ваш выбор, но я не вижу оснований для не использования x86_64.
Нет. Это не даст последовательные результаты на клиенте только для чтения из-за кэширования. Это определенно не разработано для него. Вы могли ожидать видеть ошибки IO, возвращенные к приложениям. Существует, вероятно, все еще некоторое количество надзора в коде, который мог вызвать катастрофический отказ ядра или повредить память, используемую любым процессом.
Но самое главное, ext4 воспроизводит журнал даже на монтировании только для чтения. Таким образом, монтирование только для чтения все еще запишет в базовое блочное устройство. Было бы небезопасно, даже если бы оба монтирование были только для чтения :).
Это избежит повреждения данных, но вероятно не собирается быть тем, что Вы хотите сделать. Я никогда не замечал проблем, монтирующих объем, только для чтения на другом узле. Даже если что-то обычно не совпадает на ro узле, который просто бросает "неожиданный свободный inode, выполните e2fsck" и т.п. в/var/log/messages. Если что-то будет ужасно неожиданно о некритической файловой системе ("/opt/mySpecialmount") обычно, то Linux просто смонтирует объем, только для чтения (который эй, мы уже там). Если Вы супер волнуетесь по поводу того, что имеет кэширование эффекта, можно попытаться получить своего рода drop_caches/vfs_cache_pressure движение режима.
Чтобы постараться не воспроизводить журнал добавляют "noload" к монтированию args, сделайте это наряду с errors=remount-ro (только для допущения ошибки на стороне осторожности).
Тем не менее возможности состоят в том, что, если Вы соглашаетесь с монтированием его только для чтения, это, вероятно, так же, как ссылка для другого узла, в этом случае NFS или smbfs решили бы проблему и разработаны для немного большего параллелизма, чем ext3/4 был бы. При необходимости в производительности затем, Вы могли бы изучить кластерную файловую систему (немного больше административных издержек, но это там, если производительность действительно - что-то, в чем Вы нуждаетесь).
-
1"Это избежит повреждения данных": это не может, видеть ответ sourcejedi и мой комментарий. – Totor 22.03.2013, 15:14
-
2"пропуск воспроизведения журнала приведет к файловой системе, содержащей несоответствия, которые могут привести к любому количеству проблем"-
man mount. Я могу предположить, что существуют приложения, которые обнаружили бы и/или терпели бы непоследовательные данные в их файлах, но Вы не упомянули никакой подобный протест до сих пор :). – sourcejedi 22.03.2013, 15:17 -
3@sourcejedi Они говорят это, потому что они пытаются сказать людям риски об эффективном ограничивании журнала. Это в порядке, потому что предположение - то, что другой узел будет делать работу журнала для другого узла, мы просто стараемся избегать двойной работы. Мы делаем это на одном из наших серверов разработки (не мой выбор, я сделал бы NFS), и смонтировали ту вещь даже без drop_caches для близко к году без любых проблем вообще. Мы оба упомянули, что неустаревшие записи кэша FS могут представить старые данные, но это в конечном счете до администратора, чтобы решить, осуществимо ли это. – Bratchley 22.03.2013, 15:23
-
4я не собираюсь пытаться перечислить всю неправильность в вышеупомянутом комментарии. Но как одна точка данных, это не примерно устаревшие данные файла в кэше VFS. ext4 будет иметь кэши файловой системы внутренними структурами данных ("метаданные") также. Вы могли закончить тем, что считали данные из удаленного файла, который был впоследствии перезаписан новым файлом. Это - вид протеста, о котором Вы действительно хотите знать заранее, даже если он только собирается произойти нечасто. – sourcejedi 22.03.2013, 15:40
-
5Оглядывание назад на комментарий, я думаю, что можно пытаться обратиться к кэшированию блочного уровня, которое кэширует блочного устройства ввод-вывод в памяти. В этом случае это не кэшируется, который происходит в самих метаданных, это кэшируется самих метаданных. Это также существует за пределами любых драйверов файловой системы, таким образом, ext4/btrfs/etc не имеют никакого управления им. – Bratchley 22.03.2013, 16:01
blockdev --setro /dev/sda1. – Totor 22.03.2013, 15:07sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/digital-forensics.sans.org/blog/2011/06/14 / … – isaaclw 31.01.2014, 01:02