https://www.opennet.ru/openforum/vsluhforumID3/41473.html Евгений Поляков объявил (http://tservice.net.ru/~s0mbre/blog/devel/fs/2008_04_25.html) о выходе релиза POHMELFS (http://tservice.net.ru/~s0mbre/old/?section=projects&item=pohmelfs), высокопроизводительной сетевой файловой системы с поддержкой кэширования данных и мета-данных на стороне клиента. Основная цель проекта - разработка средства для распределённой параллельной обработки данных. <br><br><br>POHMELFS находится на начальной стадии развития, многие задуманные возможности еще не реализованы. Релиз включает в себя концептуальный код сервера и клиента, работающих как пользовательские приложения.<br><br><br>Основные возможности:<br><br><br>- Поддержание локального кэша для данных и мета-данных, согласованного для всех узлов использующих ФС;<br>- Обработка данных и событий в асинхронном режиме, за исключением операций с жёсткими и символическими ссылками;<br>- Гибкая архитектура, оптимизированная для обмена данных по сети, включая возможность объединения нескольких операций в одну управляющую команду переда...<br><br>URL: http://tservic https://www.opennet.ru/openforum/vsluhforumID3/41473.html#109 Tue, 06 May 2008 15:00:15 GMT &gt;http://wiki.lustre.org/index.php?title=Lustre_OSS/MDS_with_ZFS_DMU <br>&gt;если вы тут найте слово fuse, я вам доставлю ящик пива куда <br>&gt;скажете. <br>&gt;Вот это реальность - а не ваши "предположения". <br>&gt;Которые отстают от действительности - как земля от луны. <br><br>Кстати, из вашей ссылки (не в продолжение флейма, уже надоело, нам вряд-ли переубедить друг друга):<br><br>hg clone http://www.wizy.org/mercurial/zfs-lustre<br><br>Вот там (в исходниках, changelog и т.д.) очень много слов fuse-zfs :)<br> https://www.opennet.ru/openforum/vsluhforumID3/41473.html#108 Mon, 05 May 2008 10:25:48 GMT &gt;&gt;RPC - remote procedure call. любое сообщение по которому получатель должен выполнить <br>&gt;&gt;некоторое действие - во всяком случае в обычном контексте. <br>&gt;<br>&gt;Я всегда считал, что RPC вызывает клиент, а выполняет сервер. Впрочем, вероятно <br>&gt;любые команды можно рассматривать как удаленный вызов каких-то функций. <br><br>проще говорить отправитель/получатель - тогда нет путаницы с сервер/клиент.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/41473.html#107 Mon, 05 May 2008 08:32:52 GMT &gt;RPC - remote procedure call. любое сообщение по которому получатель должен выполнить <br>&gt;некоторое действие - во всяком случае в обычном контексте. <br><br>Я всегда считал, что RPC вызывает клиент, а выполняет сервер. Впрочем, вероятно любые команды можно рассматривать как удаленный вызов каких-то функций.<br> https://www.opennet.ru/openforum/vsluhforumID3/41473.html#106 Mon, 05 May 2008 07:40:56 GMT &gt;&gt;причем тут lseek? <br>&gt;<br>&gt;При том, что если два потока не синхронизированы, запись может происходить вообще <br>&gt;в любое место файла. А с учетом того, что обновление 64битной <br>&gt;переменной не атомарно (f_pos) на 32битной архитектуре, то при запуске этого <br>&gt;приложения например в gdb (или при ptrace'инге) там может быть значение <br>&gt;наполовину их одного потока, а наполовину из другого. <br><br>для этого делаются блокировки.<br><br>&gt;<br>&gt;&gt;Пишется буфер, позиция берется из f_pos, которая на момент open(,O_APPEND) берется из <br>&gt;&gt;i_size - все согластно POSIX. <br>&gt;<br>&gt;И только в этом случае f_pos устанавливается под i_mutex'ом. <br><br>или под dlm локингом.<br><br>&gt;<br>&gt;Это я к тому, что вы в любом случае должны (кроме как <br>&gt;для O_APPEND) синхронизировать запись в файл между двумя потоками, и это <br>&gt;не задача VFS или файловой системы следить за атомарностью записи. <br><br>ну ну.. у каждого свое виденье - лиш бы это не приводило к data corruption :)<br><br><br>&gt;[оверквотинг удален]<br>&gt;транзакции (там есть open intent, где сейчас передается только O_R https://www.opennet.ru/openforum/vsluhforumID3/41473.html#105 Mon, 05 May 2008 06:42:03 GMT &gt;причем тут lseek? <br><br>При том, что если два потока не синхронизированы, запись может происходить вообще в любое место файла. А с учетом того, что обновление 64битной переменной не атомарно (f_pos) на 32битной архитектуре, то при запуске этого приложения например в gdb (или при ptrace'инге) там может быть значение наполовину их одного потока, а наполовину из другого.<br><br>&gt;Пишется буфер, позиция берется из f_pos, которая на момент open(,O_APPEND) берется из <br>&gt;i_size - все согластно POSIX. <br><br>И только в этом случае f_pos устанавливается под i_mutex'ом.<br><br>Это я к тому, что вы в любом случае должны (кроме как для O_APPEND) синхронизировать запись в файл между двумя потоками, и это не задача VFS или файловой системы следить за атомарностью записи.<br><br>Кстати, пока я писал этот ответ, подумал, что проще передавать O_APPEND в транзакции (там есть open intent, где сейчас передается только O_RDWR/O_RDONLY). Нужно поэкспериментировать.<br><br>&gt;хотел бы я посмотреть на rpc трафик в этом случае. ну да <br>&gt;лана. <br><br>Вы показывае https://www.opennet.ru/openforum/vsluhforumID3/41473.html#104 Sun, 04 May 2008 21:21:41 GMT <br><br>&gt;[оверквотинг удален]<br>&gt;&gt;Еще раз подчеркиваю <br>&gt;&gt;клиент1: statfs inode, open(O_APPEND); sleep <br>&gt;&gt;клиент2: open(,O_APPEND); write, exit; <br>&gt;&gt;клиент1: write, exit <br>&gt;&gt;по времени эти 2 действия не пересекаются - только i_size обновляется асинхронно. <br>&gt;&gt;<br>&gt;&gt;такая последовательность действий запрещена с точки зрения pohmelfs ? <br>&gt;<br>&gt;Печально... Запустите этот код параллельно в двух потоках, только в один из <br>&gt;них добавьте lseek(). <br><br>причем тут lseek? <br><br>&gt;[оверквотинг удален]<br>&gt;&gt;&gt;поток может вызвать lseek() и переписать указатель, откуда надо делать write(). <br>&gt;&gt;&gt;Для этого и изобрели pwrite() и остальных (собственно, они и используются <br>&gt;&gt;&gt;в pohmelfs server). <br>&gt;&gt;<br>&gt;&gt;в случае люстры - 2 клиента могут писать в EOF последовательно и <br>&gt;&gt;это будет работать. <br>&gt;&gt;у вас это запрещено - ок, запишем. <br>&gt;<br>&gt;Вы не видите ошибки в этом коде, печально... sys_write() работает со смещением, <br>&gt;а не с размером иноды. <br><br>ээ.. можно уточнить в каком из ядер вдруг появилось смещение?<br><br>asmlinkage ssize_t sys_write(uns https://www.opennet.ru/openforum/vsluhforumID3/41473.html#103 Sun, 04 May 2008 20:52:41 GMT <br>&gt;Нет, вы пытаетесь показать, что это не удастся. Но вы не правы <br>&gt;:) <br>&gt;Это не ядерная физика, так что сложного в этом нет ничего, просто <br>&gt;нужно немного больше двух месяцев, но вы очень не хотите сравнить <br>&gt;развитие любой другой ФС за это время. <br><br>Почитал, что из себя представляла Lustre в конце 2003 года... И эти люди запрещают мне ковыряться в носу.<br><br>Удачи.<br> https://www.opennet.ru/openforum/vsluhforumID3/41473.html#102 Sun, 04 May 2008 20:21:42 GMT &gt;&gt;Из чего вы сделали такой вывод о производительности метаданных? <br>&gt;<br>&gt;хотя бы из ваших слов о fcntl lock - что они не <br>&gt;быстрые, есть такая буква. <br>&gt;И о структуре транзакций. <br><br>Это была заметка о том, что они в VFS медленные (из-за чего от них отказались все более или менее производительные базы данных, а для синхронизации между процессами используют разделяемую память или futexes).<br><br>&gt;&gt;&gt;так же как и при журналировании данных. <br>&gt;&gt;<br>&gt;&gt;Ога, а кто дожидется, что запись в журнал завершена :) <br>&gt;<br>&gt;клиент - для этого есть средства. в Lustre book об этом была <br>&gt;помоему глава. <br><br>:) А я о чем? О том, что клиент дожидается окончания транзакции, чтобы узнать, что данные записаны. При этом он может запустить параллельно другую транзакцию, но не может освободить данные первой.<br><br>&gt;&gt;Статистика _пока_ не синхронизируется, это раз. <br>&gt;<br>&gt;но ведь это уже названо релизом? скажите что это глубокая альфа - <br>&gt;я оставлю свои коментарии :) или что я об этом не <br>&gt;думал. <br><br>Смотря с чем сравнивать, пока только с NFS можно https://www.opennet.ru/openforum/vsluhforumID3/41473.html#101 Sun, 04 May 2008 19:45:57 GMT &gt;<br>&gt;&gt;то есть разговора о производительности метаданных не идет ? <br>&gt;&gt;для решения вопросов о локах - у люстры свой lockd, это один <br>&gt;&gt;из самых обольших ее кусков. <br>&gt;<br>&gt;Из чего вы сделали такой вывод о производительности метаданных? <br><br>хотя бы из ваших слов о fcntl lock - что они не быстрые, есть такая буква.<br>И о структуре транзакций.<br><br>&gt;<br>&gt;&gt;так же как и при журналировании данных. <br>&gt;<br>&gt;Ога, а кто дожидется, что запись в журнал завершена :) <br><br>клиент - для этого есть средства. в Lustre book об этом была помоему глава.<br><br><br><br>&gt;<br>&gt;&gt;&gt;Надеюсь, что вы не пишете такой код... Задайте тот же самый вопрос, <br>&gt;&gt;&gt;если у вас два потока, один делает lseek(), а второй просто <br>&gt;&gt;&gt;write(). И тоже самое будет с двумя клиентами pohmelfs. <br>&gt;&gt;<br>&gt;&gt;судя по вашим словам "статистика не сихнронизиуется" - первый клиент будет иметь <br>&gt;<br>&gt;Статистика _пока_ не синхронизируется, это раз. <br><br>но ведь это уже названо релизом? скажите что это глубокая альфа - я оставлю свои коментарии :) или что я об этом не думал.<br><br><br>&gt;[оверквотинг