"Пара-файловая" система (или вопросы знатокам на приз хрустального осла.)

[dimbor]

Как уже где-то тут писал, на покорение паравиртуальных ксеновских вершин был подвигнут трудноуловимым отвратительным поведением вражеских технологий в линуксовом ядре. (Это когда проброс клиентской cifs-шары через nx пару раз сервер завесил вусмерть.) После чего родилась схема: Все пупер-важные безотказные сервисы работают в Dom0, а проблемные терминалы пока будут жить в гостевой до выяснения, так сказать. Но в процессе реализации возникли подозрения, что вручить осла надо мне, не хрустального, живого - того, что в зеркале.
Запустил гостя с lvm-раздела, обрадовался - работает. Наивно решил скопировать в гостя свой .bashrc и, не останавливая, примонтировал тот-же раздел под Dom0. Скопировал - гость на манипуляцию с fs, минуя его ядро, естественно не отреагировал. Вернее отреагировал fsck - потерянным inode при следущем запуске. Тут-то и стали закрадываться смутные сомнения. Ладно системный раздел гостя - есть множество кошерных способов: scp, sftp, nfs, ... А вот данные как разделить прозрачно на уровне файловой системы? В смысле между Dom0 и гостем. Может существует на свете не сетевая файловая система, позволяющая с собой подобные выкрутасы (==перечитывающая свои структуры с диска по событию)?
А то с одной стороны любое сетевое подключение будет нарушением условий воспроизведения отлавливаемого бага и нехилым снижением производительности. С другой - в погоне за этим багом традиционным способом апериодически наступает коллапс главного процесса "купи-продай хз чего". За который... по голове гладят.

[rm_]

dimbor

Может существует на свете не сетевая файловая система, позволяющая с собой подобные выкрутасы

Кластерные файловые системы, расчитанные на обращение к одному устройству хранения сразу множества нод кластера, работают именно так.
тыц: https://en.wikipedia.org/wiki/Cluster_file_system
Но в вашем случае более прямым вариантом (Оккам одобряэ) видится просто монтирование на всех нодах одной и той же CIFS/NFS-шары.

[Bluetooth]

Запустил гостя с lvm-раздела, обрадовался - работает. Наивно решил скопировать в гостя свой .bashrc и, не останавливая, примонтировал тот-же раздел под Dom0. Скопировал - гость на манипуляцию с fs, минуя его ядро, естественно не отреагировал. Вернее отреагировал fsck - потерянным inode при следущем запуске. Тут-то и стали закрадываться смутные сомнения. Ладно системный раздел гостя - есть множество кошерных способов: scp, sftp, nfs, ... А вот данные как разделить прозрачно на уровне файловой системы? В смысле между Dom0 и гостем. Может существует на свете не сетевая файловая система, позволяющая с собой подобные выкрутасы (==перечитывающая свои структуры с диска по событию)?
А то с одной стороны любое сетевое подключение будет нарушением условий воспроизведения отлавливаемого бага и нехилым снижением производительности. С другой - в погоне за этим багом традиционным способом апериодически наступает коллапс главного процесса "купи-продай хз чего". За который... по голове гладят.

Ну, такое умеет только zfs в солярке. А в линуксе даже в ридонли монтировать нельзя фс с работающего домена - он ее распознает как "сломаную", сам переводит в режим rw на время восстановления и "восстанавливает", и фс может от этого побиться. Конечно, кластерные фс можно использовать в таком виде, но стоит ли оно того? На мой взгляд, проще просто отказаться от такой нездоровой идеи и передавать файлы по сети.

[vr13]

попробуйте это. если из описания аккуратно вырезать все, что связано с drbd, то получается вполне компактная конструкция в виде общей файловой системы для всех linux (включая dom0), что работают под управлением одного гипервизора с приемлемой производительностью. с drbd - можно объединить несколько физических компьютеров

[dimbor]

Но в вашем случае более прямым вариантом (Оккам одобряэ) видится просто монтирование на всех нодах одной и той же CIFS/NFS-шары.

Если бы господин Оккам имел дело с модулем etercifs, он бы сразу стал лысым, как коленка. И в шалостях с бритвой не было бы ни потребности, ни желания. Можно считать, он вовремя соскочил.

2Bluetooth: Собственно то же самое, тем более сам подтвердил загадочность этеркифса в гостях. Отказаться то всегда можно, но мне не работать - багу поймать надоть. Коль на стенде не ловится, хоть с наименьшими потерями.
Вот и кручу-верчу.

попробуйте это. если из описания аккуратно вырезать все, что связано с drbd, то получается вполне компактная конструкция в виде общей файловой системы для всех linux (включая dom0), что работают под управлением одного гипервизора с приемлемой производительностью. с drbd - можно объединить несколько физических компьютеров

Ага. Под "этим" подразумевается OCFS2. Может быть решением, даже и не только для конкретного случая. Спасибо.

Также спасибо всем за блиц-ликбез по кластерным FS. В случае победы обязуюсь отписать.

[Bluetooth]

2Bluetooth: Собственно то же самое, тем более сам подтвердил загадочность этеркифса в гостях. Отказаться то всегда можно, но мне не работать - багу поймать надоть. Коль на стенде не ловится, хоть с наименьшими потерями.
Вот и кручу-верчу.

Аааа, багу ловить. Тогда другое дело
Кстати, подобные баги регулярно получал на терминале на 1с 7.7, с 20 пользователями, плавно мигрировавших с терминала на винде на терминал на дебиане. Чуть не застрелился, пока переводил(стоило поднапрячься, позвать помощника и перевести всех за выходные) (:
Только это все я получал безо всякой проброски срествами NX(как-то изначально стараюсь это не использовать), а в остальном все так же, как у тебя: nxagent начинает намертво вешать одно ядро. Потом еще один агент виснет, потом сервер встает. Впрочем, не до конца, продолжает шевелиться, но выключаться не желает, приходится domu прибивать.
Когда всех людей перевел на дебиановский терминал, убрал базу с cifs шары, сразу легче стало - зависания прекратились, да и скорости прибавилось порядочно. Правда, агенты повисать повисать продолжали, но уже редко(etercifs остался для доступа к шарам на файлсервере), потом же убрал etercifs из системы совсем(apt-get purge ), и стало щастье