>>Из чего вы сделали такой вывод о производительности метаданных?
>
>хотя бы из ваших слов о fcntl lock - что они не
>быстрые, есть такая буква.
>И о структуре транзакций. Это была заметка о том, что они в VFS медленные (из-за чего от них отказались все более или менее производительные базы данных, а для синхронизации между процессами используют разделяемую память или futexes).
>>>так же как и при журналировании данных.
>>
>>Ога, а кто дожидется, что запись в журнал завершена :)
>
>клиент - для этого есть средства. в Lustre book об этом была
>помоему глава.
:) А я о чем? О том, что клиент дожидается окончания транзакции, чтобы узнать, что данные записаны. При этом он может запустить параллельно другую транзакцию, но не может освободить данные первой.
>>Статистика _пока_ не синхронизируется, это раз.
>
>но ведь это уже названо релизом? скажите что это глубокая альфа -
>я оставлю свои коментарии :) или что я об этом не
>думал.
Смотря с чем сравнивать, пока только с NFS можно :)
Был бы под рукой быстрый интернет, я бы посмотрел на первый релиз Lustre...
>>Вы разве не видите огромный race в этом случае для локального VFS
>>и двух потоков?
>
>нету там race для локального VFS. оба клиента в этом случае работают
>с одной struct inode
>и i_size будет одинаковый, а в вашем случае это не так. Оба
>клиента разделены по сети, и i_size у них разный. Нарушение POSIX.
Только запись будет неизвестно куда...
>Еще раз подчеркиваю
>клиент1: statfs inode, open(O_APPEND); sleep
>клиент2: open(,O_APPEND); write, exit;
>клиент1: write, exit
>по времени эти 2 действия не пересекаются - только i_size обновляется асинхронно.
>
>такая последовательность действий запрещена с точки зрения pohmelfs ?
Печально... Запустите этот код параллельно в двух потоках, только в один из них добавьте lseek().
Этот код содержит race condition, его _нельзя_ запускать ни на какой ФС.
>>Так банально _НЕЛЬЗЯ_ делать, если вы заботитесь о сохранности данных, т.к. другой
>>поток может вызвать lseek() и переписать указатель, откуда надо делать write().
>>Для этого и изобрели pwrite() и остальных (собственно, они и используются
>>в pohmelfs server).
>
>в случае люстры - 2 клиента могут писать в EOF последовательно и
>это будет работать.
>у вас это запрещено - ок, запишем.
Вы не видите ошибки в этом коде, печально... sys_write() работает со смещением, а не с размером иноды.
Тем не менее обновление метаданных работает совершенно по тому же самому механизму, что и инвалидация страниц. Это я про i_size, права доступа, uig/gid (наверное нужно atime) и т.п. Собственно для этого есть структура, сильно напоминающая ту, что заполняет stat(2).
>>Еще раз повторю, что pohmelfs не будет поддерживать синзхронизацию более строгую, чем
>>локальный VFS.
>
>дай бог что бы она поддерживала хотя бы такую как есть в
>локальном VFS, пока и ее нету.
Я так полагаю, вы в этом сомневаетесь :)
>Я лиш пытаюсь показать подводные камни на этом пути, да и немного
>- не совсем привычных use case которые тем немеение существуют.
Нет, вы пытаетесь показать, что это не удастся. Но вы не правы :)
Это не ядерная физика, так что сложного в этом нет ничего, просто нужно немного больше двух месяцев, но вы очень не хотите сравнить развитие любой другой ФС за это время.
