>>Пока же у вас реализация яля NFS v2-3, где получить ESTALE при
>>одновременной записи с нескольких нод - за 2 байта, без всякого
>>failver (который уже в nfs v4 есть)
>>без поддержки когентности кэшей на нодах.
>
>failover разрабатывается прямо сейчас - транзакции перекатываются между набором серверов, >в случае выхода активного.угу. а о всяких безобразиях когда у клиентов есть данные которые не закомитили, а сервер уже упал - не забыли? не ну можно их грохать - но когда клиенты потеряют свои данные, они вас не поймут или можно сделать обработки журналов (как в люстре).
дальше 2 варианта
- писать свой сторадж с транзакциями
- использовать любую журналируемую fs добавив нужные callback.
какой вариант выберете Вы? Может быть что-то другое?
> Когерентность кэшей совсем просто - асинхронное сообщение от сервера,
>что страница перестала быть валидной (возможно сразу с данными), когда другой
>клиент пишет в заданное место.
и того фактически sync IO. прочитали - записали во время отбора лока (пусть на сторадж - пусть на другого клиента, не суть важно), truncate page, читаем опять.
>
>Данной версии pohmelfs около 2 месяцев, так что все только начинается.
если мой склероз не изменяет - то разговор о ней шел с лета прошлого года.
>
>>К примеру оцените что будет на выходе в вашем случае если 2
>>ноды начнут писать в таком режиме
>>нода1 - пишет каждый 70й байт
>>нода2 - пишет каждый 50й байт
>>будет ли у вас честные данные - или на месте кого-то будут
>>нули.
>
>Сейчас кто последним записал, те данные и будут в файле,
не интересно - назвать релизом - то что портит данные, и не в состоянии даже вернуть -ESTALE - как было бы в случае NFS.
> с включением
>когерентности (займусь сразу после failover, наверное в начале следующей недели будет),
>когда страница станет невалидной, клиент ее перечитает. Он и сейчас ее
>перечитывает при записи, если не uptodate, осталось только помечать ее таковой
>каждый раз, когда другой клиент делает запись.
заметьте я не зря сказал о partical page write. что бы получить когерентность кэшей
Класический пример ping-pong - и того sync IO, о котором вы так говорили что плохо.
а теперь усложним сценарий - 3й клиент читает постоянно данные, что он прочитает ?
