>угу. а о всяких безобразиях когда у клиентов есть данные которые не
>закомитили, а сервер уже упал - не забыли? не ну можно
>их грохать - но когда клиенты потеряют свои данные, они вас
>не поймут или можно сделать обработки журналов (как в люстре).
>дальше 2 варианта
>- писать свой сторадж с транзакциями
>- использовать любую журналируемую fs добавив нужные callback.
>какой вариант выберете Вы? Может быть что-то другое? Так в том-то и дело, что транзакции перекатываются - в случае падения сервера транзакция полностью уходит на следующий сервер. Вы мне напоминаете одержимого глупой идеей человека, который, видя первые несколько слов, достраивает смысл далее, даже не дочитав до конца. Причем уже не в первый раз.
>> Когерентность кэшей совсем просто - асинхронное сообщение от сервера,
>>что страница перестала быть валидной (возможно сразу с данными), когда другой
>>клиент пишет в заданное место.
>
>и того фактически sync IO. прочитали - записали во время отбора лока
>(пусть на сторадж - пусть на другого клиента, не суть важно),
>truncate page, читаем опять.
Либо не перечитывать, а сразу присылать от сервера сообщение об инвалидации и свежие данные. Возможно это даже лучше, нужно поэкспериментировать.
>>Данной версии pohmelfs около 2 месяцев, так что все только начинается.
>
>если мой склероз не изменяет - то разговор о ней шел с
>лета прошлого года.
Ваш склероз с вами. Первый релиз был в конце января, но потом я переписал практически с нуля клиент и сервер, так что возраст чуть более 2 месяцев. Первый коммит (mkdir fs/pohmelfs) был 10 декабря, запись появилась в начале января.
>>Сейчас кто последним записал, те данные и будут в файле,
>
>не интересно - назвать релизом - то что портит данные, и не
>в состоянии даже вернуть -ESTALE - как было бы в случае
>NFS.
А смысл? Задача тривиальна, но вы пытаетесь показать, что эта файловая система еще не все умеет? :))
Конечно не умеет, прогресс описан в блоге. Вы не принимайте так близко к сердцу то, что другие могут сделать что-то лучше (впрочем, с этим вы никогда не согласитесь). Я прекрасно понимаю, что сейчас просто глупо сравнивать функционал lustre и pohmelfs, а nfs и pohmelfs уже вполне.
И последний гвоздь - существует немалый race между записью в одно и тоже место в nfs для различных клиентов, когда не будет stale вообще. об этом вы либо не знаете, либо умалчиваете. В pohmelfs этот race расширен до момента writeback.
Вы так же будете рассказывать про поведение двух несинхронных потоков, которые пишут данные в файл через direct-io и page cache?
>[оверквотинг удален]
>>когда страница станет невалидной, клиент ее перечитает. Он и сейчас ее
>>перечитывает при записи, если не uptodate, осталось только помечать ее таковой
>>каждый раз, когда другой клиент делает запись.
>
>заметьте я не зря сказал о partical page write. что бы получить
>когерентность кэшей
>Класический пример ping-pong - и того sync IO, о котором вы так
>говорили что плохо.
>а теперь усложним сценарий - 3й клиент читает постоянно данные, что он
>прочитает ?
Это не sync io, пишуший клиент может вообще никогда не читать данные, т.к. сервер будет их ему посылать асинхронно. С читающим тоже самое - либо его страницы помечаются как невалидные, либо сервер сам ему присылает данные. нужно будет поэкспериментировать или сделать этот выбор опцией монтирования.
Но раз уж зашла речь о работе кэша: давайте для чистоты эксперимента также рассмотрим случай, когда несколько клиентов работают с данными, и их области не пересекаются, или пересекаются редко (классический пример базы данных, там даже индексы переписываются в новые места иногда). В этом случае файловая система без write-back кэша будет посылать на каждую запись сообщение по сети, при этом будет ждать ответ, и производительность свалится до плинтуса (хотя если параллеольно это делать, то может быть с сотней машин это и не будет заметно). Можете послушать на досуге LCA08 презентацию Зака Брауна из Оракла (Zach Brown) о CRFS - та же самая идея, в презентации рассказано о преимуществах write-back кэша и проблем с масштабируемостью sync-io подходов (хотя он мне рассказывал про ceph, а не lustre, с ней он давно работал).
