Евгений Поляков объявил (http://tservice.net.ru/~s0mbre/blog/devel/fs/2008_04_25.html) о выходе релиза POHMELFS (http://tservice.net.ru/~s0mbre/old/?section=projects&item=po...), высокопроизводительной сетевой файловой системы с поддержкой кэширования данных и мета-данных на стороне клиента. Основная цель проекта - разработка средства для распределённой параллельной обработки данных.
POHMELFS находится на начальной стадии развития, многие задуманные возможности еще не реализованы. Релиз включает в себя концептуальный код сервера и клиента, работающих как пользовательские приложения.
Основные возможности:
- Поддержание локального кэша для данных и мета-данных, согласованного для всех узлов использующих ФС;
- Обработка данных и событий в асинхронном режиме, за исключением операций с жёсткими и символическими ссылками;
- Гибкая архитектура, оптимизированная для обмена данных по сети, включая возможность объединения нескольких операций в одну управляющую команду переда...URL: http://tservice.net.ru/~s0mbre/blog/devel/fs/2008_04_25.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=15561
Только сервер в userspace, клиент ядерный (mount и все дела)...> Увеличение производительности получения данных от ядра через использование функции copy_to_user().
Это он имеет ввиду, что из асинхронных ядерных потоков можно писать в userspace память. Для этого он VM немного хачил, но пока до конца не довел (double page fault в блоге описан).
> Гибкая архитектура, оптимизированная для обмена данных по сети, включая возможность объединения нескольких операций в одну управляющую команду передаваемую по сети;
Это кстати он круто сделал, удаляется _все_ дерево ядра за одну команду.
>Евгений Поляков объявил (http://tservice.net.ru/~s0mbre/blog/devel/fs/2008_04_25.html) о выходе релиза POHMELFSМда... Релиз файловой системы с таким "народным" названием должен выйти 11-го января, после бурного и продолжительного ZastolieFS :-D
>>Евгений Поляков объявил (http://tservice.net.ru/~s0mbre/blog/devel/fs/2008_04_25.html) о выходе релиза POHMELFS
>
>Мда... Релиз файловой системы с таким "народным" названием должен выйти 11-го января,
>после бурного и продолжительного ZastolieFS :-DПервая версия вышла в конце января!
а все-таки классное название. буду следить за развитием :)
что-то я отстал от жизни - подобных открытых ФС уже вроде есть несколько штук, или нет?
>что-то я отстал от жизни - подобных открытых ФС уже вроде есть
>несколько штук, или нет?Вообще-то ни одной. GPFS наиболее близка к задуманному функционалу, но она закрыта. Все известные находятся полностью в userspace, поэтому не предоставляют POSIX API. Из того, что есть, ни одна система не предоставляет достаточной избыточности данных и метаданных, в некоторых есть начальная репликация метаданных, например в Lustre master-slave метадата сервер, но одного сервера недостаточно. В ceph есть распараллеливание метадата нагрузки между несколькими серверами, но ни один из них не дублируется, так что при его падении невозможно получить данные, опять же все в userspace, так что нет POSIX API, какую-нибудь базу данных не запустить. Хотя Ceph работает над этим и есть клиент, который будет привязан только к btrfs. В PVFS2 та же проблема - нет избыточности сервера метаданных. В glusterfs вообще до последнего времени не было избыточности даже данных, сейчас это работает очень нестабильно. В ядре есть несколько распределенных файловых систем (ocfs и gfs с номерами в конце), но они завязаны на userspace сервер блокировок, который ну очень кривой. RH сейчас переводит свой cluster suite с gfs на новую технологию из-за кривости дизайна GFS: блокировки на уровне блоков диска очень плохо масштабируются. OCFS2 вообще 32-битная система. Точнее она 64-битная, но использует ядерный JBD, который 32-битный. JBD2 должен быть 64-битным, но пока это только разработка для ext4.
Примерный план разработки таков:
В основном работа была над ядерной клиентской частью, userspace сервер
достаточно простой, но дальше основаная процесс будет над ним. В ближайших планах по клиентской части поддержка транзакций и блокировок. Так же инвалидация кеша данных клиентов при параллельной записи.Из-за отсутствия транзакций некоторые операции с метаданными (как например распаковка большого архива) требуют синхронной записи (т.е. запись не может стартовать, пока не создан объект), что снижает производительность (иногда до уровня NFS).
В пользовательском сервере будет добавлена возможность отвечать на lookup и readdir запросы не данными об объекте (информация, которую предоставляет системный вызов stat(2)), а адресом другого сервера, где этот объект находится, т.о. можно будет параллельно считывать данные с нескольких серверов. Пока планируется хранить целиком объекты на отдельных серверах (т.е. весь файл будет на одном сервере, пока без возможности хранить часть на одном, а часть на другом сервере, но это только пока).
Насчет асинхронного режима, imho, это наиболее интересная часть: клиент может сделать очень много запросов на чтение данных (или директории), а ответы могут приходить (вообще говоря с разных серверов, но это только в планах) в любое время и в любом порядке. Т.о. можно например "подсовывать" информацию о том, что новые объекты были добавлены в директорию (другим клиентом). Это уже реализовано, но код закоментирован в сервере, т.к. не очень понятно, нужно ли это. Таким же асинхронным способом будут приходить сообщения об инвалидации кеша.
Насчет зеркалирования: имеется ввиду возможность хранить один и тот же объект на разных корневых директориях, т.е. клиент видит только один объект, а на самом деле он был скопирован сервером например на разные машины/в разные корневые директории, чтобы не было проблем с чтением содержимого (т.е. клиент создал файл /mnt/test/1, значит он не должен видеть, что на самом деле он живет еще и в /mnt/backup/1 или /mnt/.test/1). Также в обязательном порядке будет зеркалирование с учетом имен, т.е. например '*.jpg' положить в /root1 и /root2, '*.conf' только в '/var/etc' и т.п. правила (пока в виде простейшего регулярного выражения).
Автор подробнее описал это в блоге.
>>что-то я отстал от жизни - подобных открытых ФС уже вроде есть
>>несколько штук, или нет?
>
>Вообще-то ни одной. GPFS наиболее близка к задуманному функционалу, но она закрыта.
>Все известные находятся полностью в userspace, поэтому не предоставляют POSIX API.Мисье забыл слово Lustre? честный posix API - уже существующие транзакции и блокировки, уже работает на машинках из списка Top10.
таки видимо забыли ;)
>>>что-то я отстал от жизни - подобных открытых ФС уже вроде есть
>>>несколько штук, или нет?
>>
>>Вообще-то ни одной. GPFS наиболее близка к задуманному функционалу, но она закрыта.
>>Все известные находятся полностью в userspace, поэтому не предоставляют POSIX API.
>
>Мисье забыл слово Lustre? честный posix API - уже существующие транзакции и
>блокировки, уже работает на машинках из списка Top10.
>таки видимо забыли ;)а. забыл добавить GPLv2. что бы не говорили о закрытости
>[оверквотинг удален]
>>>>несколько штук, или нет?
>>>
>>>Вообще-то ни одной. GPFS наиболее близка к задуманному функционалу, но она закрыта.
>>>Все известные находятся полностью в userspace, поэтому не предоставляют POSIX API.
>>
>>Мисье забыл слово Lustre? честный posix API - уже существующие транзакции и
>>блокировки, уже работает на машинках из списка Top10.
>>таки видимо забыли ;)
>
>а. забыл добавить GPLv2. что бы не говорили о закрытостиОдна проблема - сложность и огромная кодовая база. Из-за кривости кода его не взяли в mainline, хотя это было давно... Работает lustre с selinux на том же разделе? Сомневаюсь...
Плюс скоро будет переход на FUSE - прощай производительность. Конечно, когда параллельно работающих узлов 1000, о производительности одного речь не идет. Здесь идет.
В fuse запись большими блоками больше 4к добавили месяц назад, не знаю, вошло в mainline уже или нет.Lustre использует ext*, при выпадании машины, ее не будет несколько часов из-за fsck при достаточно больших дисках. Новые файловые системы этому не подвержены.
>[оверквотинг удален]
>>>
>>>Мисье забыл слово Lustre? честный posix API - уже существующие транзакции и
>>>блокировки, уже работает на машинках из списка Top10.
>>>таки видимо забыли ;)
>>
>>а. забыл добавить GPLv2. что бы не говорили о закрытости
>
>Одна проблема - сложность и огромная кодовая база. Из-за кривости кода его
>не взяли в mainline, хотя это было давно... Работает lustre с
>selinux на том же разделе? Сомневаюсь...работает :)
>
>Плюс скоро будет переход на FUSE - прощай производительность. Конечно, когда параллельно
>работающих узлов 1000, о производительности одного речь не идет. Здесь идет.
>
>В fuse запись большими блоками больше 4к добавили месяц назад, не знаю,
>вошло в mainline уже или нет.вы что курили? какое FUSE? дайте мне туже траву!
>
>Lustre использует ext*, при выпадании машины, ее не будет несколько часов из-за
>fsck при достаточно больших дисках. Новые файловые системы этому не подвержены.
>вот уж врать не надо ;) там далеко не ext* - хоть и похоже.
>>Плюс скоро будет переход на FUSE - прощай производительность. Конечно, когда параллельно
>>работающих узлов 1000, о производительности одного речь не идет. Здесь идет.
>>
>>В fuse запись большими блоками больше 4к добавили месяц назад, не знаю,
>>вошло в mainline уже или нет.
>
>вы что курили? какое FUSE? дайте мне туже траву!Lustre 1.8 is planned for next summer and will introduce user space servers for both Linux and Solaris, running with ZFS/DMU. We'll continue to support the existing in-kernel servers for Linux with ext3 until Lustre 2.0 at the end of the calendar year. In 2.0 we'll release clustered metadata servers, enabling the same kind of scalability for metadata that we have for storage servers today. And, although it will also mark the end of in-kernel servers and ext3, Linux will remain strategic to the future of Lustre.
http://www.sun.com/aboutsun/media/features/qa_cfs.jsp
>>Lustre использует ext*, при выпадании машины, ее не будет несколько часов из-за
>>fsck при достаточно больших дисках. Новые файловые системы этому не подвержены.
>>
>
>вот уж врать не надо ;) там далеко не ext* - хоть
>и похоже.Там _ТОЛЬКО_ ext* с тонной дополнительных патчей.
Почитайте на досуге хотя бы faq.
Плюч, imho, lustre умерла после ее продажи sun. Последним для Linux она не нужна, чтобы маркетоиды не говорили про стратегическое развитие и т.п.
>[оверквотинг удален]
>Lustre 1.8 is planned for next summer and will introduce user space
>servers for both Linux and Solaris, running with ZFS/DMU. We'll continue
>to support the existing in-kernel servers for Linux with ext3 until
>Lustre 2.0 at the end of the calendar year. In 2.0
>we'll release clustered metadata servers, enabling the same kind of scalability
>for metadata that we have for storage servers today. And, although
>it will also mark the end of in-kernel servers and ext3,
>Linux will remain strategic to the future of Lustre.
>
>http://www.sun.com/aboutsun/media/features/qa_cfs.jspи где вы увидели тут FUSE ?
zfs вполне себе может линковаться как zpool.
советую сходить на wiki разработчиков и почитать ;)>
>>>Lustre использует ext*, при выпадании машины, ее не будет несколько часов из-за
>>>fsck при достаточно больших дисках. Новые файловые системы этому не подвержены.
>>>
>>
>>вот уж врать не надо ;) там далеко не ext* - хоть
>>и похоже.
>
>Там _ТОЛЬКО_ ext* с тонной дополнительных патчей.да ну ;) вот эта тонна патчей и превращает ее
>
>Почитайте на досуге хотя бы faq.читал - и не только faq ;) не поверите.
>
>Плюч, imho, lustre умерла после ее продажи sun. Последним для Linux она
>не нужна, чтобы маркетоиды не говорили про стратегическое развитие и т.п.
>Ой. cray об этом не в курсе... HP тоже - откройте им глаза ;)
>>http://www.sun.com/aboutsun/media/features/qa_cfs.jsp
>
>и где вы увидели тут FUSE ?
>zfs вполне себе может линковаться как zpool.
>советую сходить на wiki разработчиков и почитать ;)Lustre 1.8 is planned for next summer and will introduce user space servers for both Linux and Solaris, running with ZFS/DMU. При этом sun наняла разработчика zfs-fuse.
2+2=?
http://wiki.lustre.org/index.php?title=Fuse
Клиент уже есть.
>>Там _ТОЛЬКО_ ext* с тонной дополнительных патчей.
>
>да ну ;) вот эта тонна патчей и превращает ееНо тем не менее :)
Кстати, вы парой сообщений ниже отверждаете обратное, что дескать это всего лишь экспорты, и вообще кодовая база маленькая...>>Плюч, imho, lustre умерла после ее продажи sun. Последним для Linux она
>>не нужна, чтобы маркетоиды не говорили про стратегическое развитие и т.п.
>>
>Ой. cray об этом не в курсе... HP тоже - откройте им
>глаза ;)А на cray xt* Linux? Удивлен...
Я имел ввиду, что не сама lustre не нужна, а на _Linux_. Хотя с перводом серверов в userspace какая уже разница.
>[оверквотинг удален]
>>
>>и где вы увидели тут FUSE ?
>>zfs вполне себе может линковаться как zpool.
>>советую сходить на wiki разработчиков и почитать ;)
>
>Lustre 1.8 is planned for next summer and will introduce user space
>servers for both Linux and Solaris, running with ZFS/DMU. При этом
>sun наняла разработчика zfs-fuse.
>
>2+2=?аха.. 2 яблока и 2 арбуза - не равно 4 яблока ;) user space servers != fuse.
у вас какая-то каша в голове.
>
>http://wiki.lustre.org/index.php?title=Fuse
>
>Клиент уже есть.есть - только оно не работает в люстрой из коробки, требует спец опций в libsysio - и не собирается на чем-то отличном от linux. А так - есть.
>
>>>Там _ТОЛЬКО_ ext* с тонной дополнительных патчей.
>>
>>да ну ;) вот эта тонна патчей и превращает ее
>
>Но тем не менее :)
>Кстати, вы парой сообщений ниже отверждаете обратное, что дескать это всего лишь
>экспорты, и вообще кодовая база маленькая...1. ldiskfs != lustre patch series.
2. маленькая - в 2.6.24/2.6.25 даже в ldiskfs количество патчей упадет сильно, ибо их влили в ext4. опять же - если снимательно посмотреть на ldiskfs патчи - это один большой патч для mballoc (ну что делать O(1) аллокации хочется иметь) + имплементация callback.>
>>>Плюч, imho, lustre умерла после ее продажи sun. Последним для Linux она
>>>не нужна, чтобы маркетоиды не говорили про стратегическое развитие и т.п.
>>>
>>Ой. cray об этом не в курсе... HP тоже - откройте им
>>глаза ;)
>
>А на cray xt* Linux? Удивлен...удивитесь - сильнее на HP SFS - linux + lustre, IBM BG/L - linux + lustre.
>Я имел ввиду, что не сама lustre не нужна, а на _Linux_.
>Хотя с перводом серверов в userspace какая уже разница.Не думаю что выдам большую тайну - kernel space server не будут убивать и под линухом.
>>А на cray xt* Linux? Удивлен...
>
>удивитесь - сильнее на HP SFS - linux + lustre, IBM BG/L
>- linux + lustre.Про остальных-то я знал, но про cray нет.
>>Я имел ввиду, что не сама lustre не нужна, а на _Linux_.
>>Хотя с перводом серверов в userspace какая уже разница.
>
>Не думаю что выдам большую тайну - kernel space server не будут
>убивать и под линухом.Тогда почему sun открытым текстом заявила? Зачем тогда fuse клиент (пусть и кривой и требующий патчей)? Зачем тогда нанимать zfs-fuse разработчика?
Мне видится примерно такое развитие: lustre работает поверх udmu в solaris, а в linux - поверх zfs-fuse, который опять же может экспортировать как dmu.
>>>А на cray xt* Linux? Удивлен...
>>
>>удивитесь - сильнее на HP SFS - linux + lustre, IBM BG/L
>>- linux + lustre.
>
>Про остальных-то я знал, но про cray нет.libsysio остался только у очень не большого количества клиентов.
Cray == SLES (9/10).
IBM == RHEL(4-5)
HP = RHEL(3-4)
>
>>>Я имел ввиду, что не сама lustre не нужна, а на _Linux_.
>>>Хотя с перводом серверов в userspace какая уже разница.
>>
>>Не думаю что выдам большую тайну - kernel space server не будут
>>убивать и под линухом.
>
>Тогда почему sun открытым текстом заявила?О чем? о том что будут userspace - и о том что будут убирать ldiskfs.
Будут - но не обязательно с убиванием ldiskfs - убить kernel space сервер.
> Зачем тогда fuse клиент (пусть и
>кривой и требующий патчей)? Зачем тогда нанимать zfs-fuse разработчика?Зачем нанимать zfs-fuse - не знаю, это не к нам нанимали.
возможно хотят что-то придумать и в linux - но это не в HPC наняли, анонсов о приеме этого сотрудника я не видел.
>
>Мне видится примерно такое развитие: lustre работает поверх udmu в solaris, а
>в linux - поверх zfs-fuse, который опять же может экспортировать как
>dmu.Поверьте мне "не верится", это тот код который мне прийдется сапортить - так что я интересуюсь у тех кто разрабатывает и читаю внутренную документацию.
В обоих случаях libzpool.
>>>Не думаю что выдам большую тайну - kernel space server не будут
>>>убивать и под линухом.
>>
>>Тогда почему sun открытым текстом заявила?
>
>О чем? о том что будут userspace - и о том что
>будут убирать ldiskfs.
>Будут - но не обязательно с убиванием ldiskfs - убить kernel space
>сервер....it will also mark the end of in-kernel servers and ext3...
Так что возожно не на fuse, а на свое что-то, всего быстрей на что-то завязанное на zfs (в solaris нативно, в linux через zfs-fuse, т.к. нужен userspace и udmu). Но проще всего это сделать через fuse, раз уже пробовали сделать клиент в lustre, а sun наняла zfs-fuse разработчкиа.Нет, я не говорю, что это 100% развитие событий, но часть из этого будет точно (как-то грохнуть ядерную часть), а возможно и весь сценарий отыграют через fuse.
>>Мне видится примерно такое развитие: lustre работает поверх udmu в solaris, а
>>в linux - поверх zfs-fuse, который опять же может экспортировать как
>>dmu.
>
>Поверьте мне "не верится", это тот код который мне прийдется сапортить -
>так что я интересуюсь у тех кто разрабатывает и читаю внутренную
>документацию.
>В обоих случаях libzpool.Возможно это только для 1.8, перевод в userspace обещан только в 2.0
Плюс поддержка наверняка останется.
>[оверквотинг удален]
>>Будут - но не обязательно с убиванием ldiskfs - убить kernel space
>>сервер.
>
>...it will also mark the end of in-kernel servers and ext3...
>Так что возожно не на fuse, а на свое что-то, всего быстрей
>на что-то завязанное на zfs (в solaris нативно, в linux через
>zfs-fuse, т.к. нужен userspace и udmu). Но проще всего это сделать
>через fuse, раз уже пробовали сделать клиент в lustre, а sun
>наняла zfs-fuse разработчкиа.
>еще раз говорю - его наняли не в HPC отдел. а значит к люстре отношения он не имеет.
Скорее всего пытаются сделать костыль что бы обойти глупые ограничения в linux kernel.
Хотя боюсь что тогда fuse постигнет судьба ndiswrapper - (ах там могут грузить закрытые модули), и нафик выкинут из Тру дистрибутивов.
>Нет, я не говорю, что это 100% развитие событий, но часть из
>этого будет точно (как-то грохнуть ядерную часть), а возможно и весь
>сценарий отыграют через fuse.вам не смешно? тут далеко не идиоты работают. если что-то не дает нужной производительности (напомню на IB оно дает 1200 Gbyte/s read, 800 GByte/s write)
то никто связываться не будет.
Мне тут ребята подсказывают что вам уже более одного человека писали что fuse не будет,
вы опять ее зачем-то вспоминаете.>[оверквотинг удален]
>>>dmu.
>>
>>Поверьте мне "не верится", это тот код который мне прийдется сапортить -
>>так что я интересуюсь у тех кто разрабатывает и читаю внутренную
>>документацию.
>>В обоих случаях libzpool.
>
>Возможно это только для 1.8, перевод в userspace обещан только в 2.0
>
>Плюс поддержка наверняка останется.в 1.8 не будет zfs вобще - по новому release plan. так что zpool и еще раз zpool.
я понимаю что вам не хочется отказываться от сказки от fuse - но надо смотреть правде в глаза.
>вам не смешно? тут далеко не идиоты работают. если что-то не даетВы не поверите, но я в этом не сомневаюсь :)
>нужной производительности (напомню на IB оно дает 1200 Gbyte/s read, 800
>GByte/s write)
>то никто связываться не будет.
>Мне тут ребята подсказывают что вам уже более одного человека писали что
>fuse не будет,
>вы опять ее зачем-то вспоминаете.При параллельном доступе? Да не вопрос, только машин станет в 2 раза больше... (или насколько там udmu медленее).
>>Возможно это только для 1.8, перевод в userspace обещан только в 2.0
>>
>>Плюс поддержка наверняка останется.
>
>в 1.8 не будет zfs вобще - по новому release plan. так
>что zpool и еще раз zpool.
>я понимаю что вам не хочется отказываться от сказки от fuse -
>но надо смотреть правде в глаза.Я всего лишь смотрю на данные, которые есть в открытом доступе. Лично мне все равно, что будет или не будет с lustre :)
Но слова sun настораживают, а их поступки наводят на размышления.
Давайте подведем мирный итог?По моему мнению, sun планирует перевод базы lustre в userspace в 2.0 релизе (судя по их пресс-релизу), чтобы была возможность работать как с solaris, так и linux. При этом в solaris это будет udmu, а что будет в linux не известно. При этом sun нанимает разработчика zfs-fuse, так что _мне_ это видится как работа в solaris через udmu, а в linux - dmu из zfs-fuse. Не Lustre на fuse, а то, поверх чего она запущена.
По вашему мнению, sun просто откажется от своих слов о переводе всего в userspace в linux, а будет только udmu в solaris.
>
>>нужной производительности (напомню на IB оно дает 1200 Gbyte/s read, 800
>>GByte/s write)
>>то никто связываться не будет.
>>Мне тут ребята подсказывают что вам уже более одного человека писали что
>>fuse не будет,
>>вы опять ее зачем-то вспоминаете.
>
>При параллельном доступе? Да не вопрос, только машин станет в 2 раза
>больше... (или насколько там udmu медленее).не на сколько, 6 из 18 use cases медленнее на 15% (или меньше - лень в документы смотреть). В остальных быстрее.
А с уходом от глупого vfs в линухе (для ost) - будет значительно быстрее.>[оверквотинг удален]
>>в 1.8 не будет zfs вобще - по новому release plan. так
>>что zpool и еще раз zpool.
>>я понимаю что вам не хочется отказываться от сказки от fuse -
>>но надо смотреть правде в глаза.
>
>Я всего лишь смотрю на данные, которые есть в открытом доступе. Лично
>мне все равно, что будет или не будет с lustre :)
>
>Но слова sun настораживают, а их поступки наводят на размышления.
>не делайте поспешных выводов - не разобравшись в предмете ;)
>
>Давайте подведем мирный итог?
>
>По моему мнению, sun планирует перевод базы lustre в userspace в 2.0
>релизе (судя по их пресс-релизу), чтобы была возможность работать как с
>solaris, так и linux. При этом в solaris это будет udmu,
>а что будет в linux не известно. При этом sun нанимает
>разработчика zfs-fuse, так что _мне_ это видится как работа в solaris
>через udmu, а в linux - dmu из zfs-fuse. Не Lustreнайдите в себе мужество разобраться - что такое DMU, что такое zfs-fusе!
DMU это сторадж с транзакциями. Самый ближайший аналог inodefs в FreeBSD.
собственноо это основное что делали патчи в ldiskfs, сделать сторадж с транзакциями для обхода работы с именами и иметь возможность цеплять свои callback на конец транзакций и тп.
>на fuse, а то, поверх чего она запущена.
>
>По вашему мнению, sun просто откажется от своих слов о переводе всего
>в userspace в linux, а будет только udmu в solaris.для linux будет kernel/userpace server (ибо в userspace сделано по posix и пофик на чем собирать)
для solaris - userspace server.
клиенты - везде kernel space.
>>При параллельном доступе? Да не вопрос, только машин станет в 2 раза
>>больше... (или насколько там udmu медленее).
>
>не на сколько, 6 из 18 use cases медленнее на 15% (или
>меньше - лень в документы смотреть). В остальных быстрее.
>А с уходом от глупого vfs в линухе (для ost) - будет
>значительно быстрее.:) не совсем так, при бОльших массивах слив в разы.
>>Но слова sun настораживают, а их поступки наводят на размышления.
>
>не делайте поспешных выводов - не разобравшись в предмете ;)Я делаю не выводы, а предположения, для вас же это как красная тряпка...
>[оверквотинг удален]
>>а что будет в linux не известно. При этом sun нанимает
>>разработчика zfs-fuse, так что _мне_ это видится как работа в solaris
>>через udmu, а в linux - dmu из zfs-fuse. Не Lustre
>
>найдите в себе мужество разобраться - что такое DMU, что такое zfs-fusе!
>
>DMU это сторадж с транзакциями. Самый ближайший аналог inodefs в FreeBSD.
>собственноо это основное что делали патчи в ldiskfs, сделать сторадж с транзакциями
>для обхода работы с именами и иметь возможность цеплять свои callback
>на конец транзакций и тп.Ога, а теперь посмотрим, может ли это предоставить zfs-fuse (после напильника, хотя может уже и есть)...
>
>>на fuse, а то, поверх чего она запущена.
>>
>>По вашему мнению, sun просто откажется от своих слов о переводе всего
>>в userspace в linux, а будет только udmu в solaris.
>
>для linux будет kernel/userpace server (ибо в userspace сделано по posix и
>пофик на чем собирать)
>для solaris - userspace server.
>клиенты - везде kernel space.При клиенты речь и не идет, хотя в wiki есть пример и roadmap.
Сейчас мы о сервере. Кстати, вы не раньше не говорили, что будет userspace сервер, но тем не менее, ваша сторона прямо противоположна тому, что озвучил sun.На этом и закончим.
>>>При параллельном доступе? Да не вопрос, только машин станет в 2 раза
>>>больше... (или насколько там udmu медленее).
>>
>>не на сколько, 6 из 18 use cases медленнее на 15% (или
>>меньше - лень в документы смотреть). В остальных быстрее.
>>А с уходом от глупого vfs в линухе (для ost) - будет
>>значительно быстрее.
>
>:) не совсем так, при бОльших массивах слив в разы.да ну? у вас сведения более точные чем внутренние тесты Sun?
>[оверквотинг удален]
>>
>>найдите в себе мужество разобраться - что такое DMU, что такое zfs-fusе!
>>
>>DMU это сторадж с транзакциями. Самый ближайший аналог inodefs в FreeBSD.
>>собственноо это основное что делали патчи в ldiskfs, сделать сторадж с транзакциями
>>для обхода работы с именами и иметь возможность цеплять свои callback
>>на конец транзакций и тп.
>
>Ога, а теперь посмотрим, может ли это предоставить zfs-fuse (после напильника, хотя
>может уже и есть)...вы специально говорите глупость или не берете на себя труд разобраться?
возьмите листок бумаги.. нарисуйте структуру FS по уровням.
начиная с аллокации блоков, и заканчивая директориями/файлами поверх стораджа.
zfs (хоть zfs-fuse) это самый высокий уровень, люстре столько не надо.
ей нужны более низко уровеневые веши - уровень стораджа с транзакциями.
можно понять что это 2 паралельных ветки - dmu + some directroy structure => zfs и модуль для работы с готовой zfs через fuse-api, fuse-zfs.
и вторая ветка dmu+OSS/MDS (uOSS/uMDS) - которая используется для lustre.мне честно - страшно что человек с такими знаниями берется писать файловую систему...
>>:) не совсем так, при бОльших массивах слив в разы.
>
>да ну? у вас сведения более точные чем внутренние тесты Sun?Насколько я помню, это именно я их привел в треде, хотя да, из рассылки lustre.
Тесты ноября 2007?>вы специально говорите глупость или не берете на себя труд разобраться?
>возьмите листок бумаги.. нарисуйте структуру FS по уровням.
>начиная с аллокации блоков, и заканчивая директориями/файлами поверх стораджа.
>zfs (хоть zfs-fuse) это самый высокий уровень, люстре столько не надо.
>ей нужны более низко уровеневые веши - уровень стораджа с транзакциями.
>можно понять что это 2 паралельных ветки - dmu + some directroy structure => zfs и модуль для работы с готовой zfs через fuse-api, fuse-zfs.
>и вторая ветка dmu+OSS/MDS (uOSS/uMDS) - которая используется для lustre.Не важно, что lustre не нужен такой высокий уровень абстракции, как может предоставить zfs-fuse, может быть от нее возмут только часть, может быть все, мы этого не знаем.
Важно то, что для sun будет единое хранилище - как под linux, так и под solaris, пусть даже с дополнительными накладными под linux, зато отлично нативно под solaris.
>мне честно - страшно что человек с такими знаниями берется писать файловую
>систему...Слабовато... надо сильнее давить на личности :)
Кстати, вы не ответили про тип кэша в lustre. Write-through и только в памяти? Или скатывается на синхронную запись, когда несколько клиентов открывают один и тот же файл?
Мне действительно интересно :)
>Кстати, вы не ответили про тип кэша в lustre. Write-through и только
>в памяти? Или скатывается на синхронную запись, когда несколько клиентов открывают
>один и тот же файл?
>Мне действительно интересно :)Зависит от локов. если локи не пересекаются - синхронной записи не будет.
каждый может писать в свой диапазон и не мешать другим.В общем случае запись всегда асинхронна, синхронная запись используется в 2х случаях
1. у клиента отбирают лок на диапазон в файле, синхронная запись используется для поддержкания когентности кэшей. На сколько в курсе этот кусок сейчас переделывается - для прямой передачи другому клиенту.2. Когда клиент не знает сколько свободного места он может записать, один rpc уходит в sync write, в при следующем ответе от OST клиент получит обновление - и будет писать в async.
я ответил на Ваш вопрос?
>я ответил на Ваш вопрос?Практически. Т.е. при одновременной записи в одно место получается синхронная запись, но сейчас это переделывают на что-то типа grant leases/grant operation в nfs4.1.
Первая часть (про синхронную запись) используется так же в ceph, получаются серьезные проблемы. Вторая (будет?) в pnfs.Это я к тому, что в pohmelfs используется write-back кэш, хотя пока без byte-range блокировок, подход иной, теоретически должен дать ощутимый прирост для многопоточных/многоклиентских приложений с работой с одним и тем же файлом, как например базы данных.
>
>>я ответил на Ваш вопрос?
>
>Практически. Т.е. при одновременной записи в одно место получается синхронная запись, но
>сейчас это переделывают на что-то типа grant leases/grant operation в nfs4.1.не совсем.
>
>Первая часть (про синхронную запись) используется так же в ceph, получаются серьезные
>проблемы.
> Вторая (будет?) в pnfs.
>
>Это я к тому, что в pohmelfs используется write-back кэш, хотя пока
>без byte-range блокировок, подход иной, теоретически должен дать ощутимый прирост для
>многопоточных/многоклиентских приложений с работой с одним и тем же файлом, как
>например базы данных.база данных работает с 1 файлом, но крайне редко пишет в одно место - однако записи для этого предназначены.
опять же - вопросы блокировок и поддержание когентности кэшей на большом количестве нод - это отдельная песня - одна нода пишет, вторая читает, любимая ситуация с записью неполной страницы (блока) - когда надо еще прочитать остаток.
Пока же у вас реализация яля NFS v2-3, где получить ESTALE при одновременной записи с нескольких нод - за 2 байта, без всякого failver (который уже в nfs v4 есть)
без поддержки когентности кэшей на нодах.К примеру оцените что будет на выходе в вашем случае если 2 ноды начнут писать в таком режиме
нода1 - пишет каждый 70й байт
нода2 - пишет каждый 50й байт
будет ли у вас честные данные - или на месте кого-то будут нули.
>Пока же у вас реализация яля NFS v2-3, где получить ESTALE при
>одновременной записи с нескольких нод - за 2 байта, без всякого
>failver (который уже в nfs v4 есть)
>без поддержки когентности кэшей на нодах.failover разрабатывается прямо сейчас - транзакции перекатываются между набором серверов, в случае выхода активного. Когерентность кэшей совсем просто - асинхронное сообщение от сервера, что страница перестала быть валидной (возможно сразу с данными), когда другой клиент пишет в заданное место.
Данной версии pohmelfs около 2 месяцев, так что все только начинается.
>К примеру оцените что будет на выходе в вашем случае если 2
>ноды начнут писать в таком режиме
>нода1 - пишет каждый 70й байт
>нода2 - пишет каждый 50й байт
>будет ли у вас честные данные - или на месте кого-то будут
>нули.Сейчас кто последним записал, те данные и будут в файле, с включением когерентности (займусь сразу после failover, наверное в начале следующей недели будет), когда страница станет невалидной, клиент ее перечитает. Он и сейчас ее перечитывает при записи, если не uptodate, осталось только помечать ее таковой каждый раз, когда другой клиент делает запись.
>>Пока же у вас реализация яля 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й клиент читает постоянно данные, что он прочитает ?
>угу. а о всяких безобразиях когда у клиентов есть данные которые не
>закомитили, а сервер уже упал - не забыли? не ну можно
>их грохать - но когда клиенты потеряют свои данные, они вас
>не поймут или можно сделать обработки журналов (как в люстре).
>дальше 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, с ней он давно работал).
BTW - хорошо бы еще задумываться о возможности храненения данных на разных нодах - lov уровень в люстре. И частей одной директории на разных серверах метаданных - lmv уровень люстры.
>BTW - хорошо бы еще задумываться о возможности храненения данных на разных
>нодах - lov уровень в люстре. И частей одной директории на
>разных серверах метаданных - lmv уровень люстры.Так и будет. Loopkup/readdir будет расширен на возвращение информации не только о локальных данных, но так же с адресом сервера, гда они находятся.
>>BTW - хорошо бы еще задумываться о возможности храненения данных на разных
>>нодах - lov уровень в люстре. И частей одной директории на
>>разных серверах метаданных - lmv уровень люстры.
>
>Так и будет. Loopkup/readdir будет расширен на возвращение информации не только о
>локальных данных, но так же с адресом сервера, гда они находятся.
>В догонку - кто будет выделять inode number (в случае люстры fid number) - клиент/сервер?
Еще такой забавный набор флагов у open -
open(,O_RW|O_CREATE|O_TRUNCATE).
замете надо это сделать атомарно, а не как 2-3 последовательных команды.
>
>В догонку - кто будет выделять inode number (в случае люстры fid
>number) - клиент/сервер?Здесь иной подход: номера инод не синхронизируются с сервером и между клиентами, вместо этого сипользуется полный путь. Поэтому нет необходимости в кривом open_by_inode/open_by_cookie как в nfs и без проблем с перемещенными объектами.
>Еще такой забавный набор флагов у open -
>open(,O_RW|O_CREATE|O_TRUNCATE).
>замете надо это сделать атомарно, а не как 2-3 последовательных команды.Для транзакции (open intent) существует набор флагов, передаваемый на сервер, там они используются как аргумент для open/mkdir и т.д.
>>
>>В догонку - кто будет выделять inode number (в случае люстры fid
>>number) - клиент/сервер?
>
>Здесь иной подход: номера инод не синхронизируются с сервером и между клиентами,
>вместо этого сипользуется полный путь. Поэтому нет необходимости в кривом open_by_inode/open_by_cookie
>как в nfs и без проблем с перемещенными объектами.что-то мне говорит что это будет тормоз при любых операциях связаных с metadata.
ибо nfs кэширует открытый файл и через куки находит ее, а так при каждой операции записи надо будет делать преобразование имя -> inode.
Я не прав ?
я так же не пойму где в вашей схеме место generation у inode. путь не изменился - а данные там уже другие.
Примерно вот такой test case:
>>>>>>>>>cp -f /bin/bash $DIR1/$tdir/bash
/bin/sh -c 'sleep 1; rm -f $DIR2/$tdir/bash; cp /bin/bash $DIR2/$tdir' &
err=$($DIR1/$tdir/bash -c 'sleep 2; openfile -f O_RDONLY /proc/$$/exe >& /dev/null; echo $?')
>>>>>>>>>>>>
>
>>Еще такой забавный набор флагов у open -
>>open(,O_RW|O_CREATE|O_TRUNCATE).
>>замете надо это сделать атомарно, а не как 2-3 последовательных команды.
>
>Для транзакции (open intent) существует набор флагов, передаваемый на сервер, там они
>используются как аргумент для open/mkdir и т.д.дело в том что truncate может быть сделан с другой ноды, и create с другой ноды.
а глобального семафора как в случае VFS - не будет, или если будет - будут тормоза.
я не увидел ответа на счет работы транзакций и replay у журнала транзакций, и коментарий на счет пседво-sync_io в случае записи с разных клиентов в пределы страницы.
можно немного пояснений?
>что-то мне говорит что это будет тормоз при любых операциях связаных с
>metadata.Это что-то вам неправильно говорит, tar -xf really_large_archive_from_tmpfs.tar примерно в 3 раза быстрее на pohmelfs чем async nfs. В 2 раза с диска, т.к. уперлись в его скорость (скорость xfs на нем).
>дело в том что truncate может быть сделан с другой ноды, и
>create с другой ноды.
>а глобального семафора как в случае VFS - не будет, или если
>будет - будут тормоза.А если у вас два несинхронных потока работают с VFS, один делает open/create,а другой truncate, что будет? В VFS лочится инода, она же будет лочиться на сервере, когда два потока получат сообщения от своих клиентов о том, что пора делать create/truncate.
>я не увидел ответа на счет работы транзакций и replay у журнала
>транзакций, и коментарий на счет пседво-sync_io в случае записи с разных
>клиентов в пределы страницы.
>можно немного пояснений?Транзакция содержит набор команд, выполняемых атомарно (в смысле клиент ждет, пока придет ответ, что транзакция готова). например создать файл и записать в него 10 страниц данных. Если в середине этой транзакции сервер отваливается, клиент переходит на следующий (для каждой конфигурации можно задавать их сколько угодно) и посылает ему ту же самую транзакцию. сервер должен ее получить, раздать всем воим зеркалам и прислать (если есть такой флаг) ответ, что все в порядке.
Запись в пределах одной страницы лочит страницу и пишет данные. Если после лока страница оказалась не uptodate, она считывается с сервера (это по умолчанию уже реализовано), либо сообщение, которое помечает страницу как не uptodate может содержать сами данные, поэтому последующая запись в нее будет корректной. Этого пока нет, как, впрочем, и самого механизма когерентности кэшей. Код для когерентности метаданных (в директории появился новый объект например) есть и был протестирован, но я не вижу особого смысла в этом, поэтому пока он закомментирован на сервере.
Все синхронизации делаются не строже, чем в случае локальной работы нескольких потоков с одним и тем же файлом.
>
>>дело в том что truncate может быть сделан с другой ноды, и
>>create с другой ноды.
>>а глобального семафора как в случае VFS - не будет, или если
>>будет - будут тормоза.
>
>А если у вас два несинхронных потока работают с VFS, один делает
>open/create,а другой truncate, что будет? В VFS лочится инода, она же
>будет лочиться на сервере, когда два потока получат сообщения от своих
>клиентов о том, что пора делать create/truncate.это подходит только в случае когда данные находятся на том же сервере что и meta-data.
тогда вы перекладываете работу которую вам надо сделать - на плечи vfs.
>[оверквотинг удален]
>>можно немного пояснений?
>
>Транзакция содержит набор команд, выполняемых атомарно (в смысле клиент ждет, пока придет
>ответ, что транзакция готова). например создать файл и записать в него
>10 страниц данных. Если в середине этой транзакции сервер отваливается, клиент
>переходит на следующий (для каждой конфигурации можно задавать их сколько угодно)
>и посылает ему ту же самую транзакцию. сервер должен ее получить,
>раздать всем воим зеркалам и прислать (если есть такой флаг) ответ,
>что все в порядке.
>Клиент обязан дождаться когда транзакция закончится, и новая транзакция не откроется до тех пор пока не закончена старая? иначе мы имеем очень большое окно между тем как мы закрыли транзакцию - и тем как она реально закомичена на сервере.
>
>Запись в пределах одной страницы лочит страницу и пишет данные. Если после
>лока страница оказалась не uptodate, она считывается с сервера (это по
>умолчанию уже реализовано), либо сообщение, которое помечает страницу как не uptodate
>может содержать сами данные, поэтому последующая запись в нее будет корректной.
>Этого пока нет, как, впрочем, и самого механизма когерентности кэшей. Код
>для когерентности метаданных (в директории появился новый объект например) есть и
>был протестирован, но я не вижу особого смысла в этом, поэтому
>пока он закомментирован на сервере.
>клиент делает statfs - при этом другой клиент пишет (изменяет размер).
какой размер увидит первый клиент? будет ли повторно запрашиваться атрибуты файлов если сделать 2 раза ls -l на каталоге с 100к файлов?>Все синхронизации делаются не строже, чем в случае локальной работы нескольких потоков
>с одним и тем же файлом.в случае локальной работы - за вас всю синхронизацию делает vfs.
в случае сетевой работы (при нескольких нодах) - вам это прийдется делать за vfs.
>это подходит только в случае когда данные находятся на том же сервере
>что и meta-data.
>тогда вы перекладываете работу которую вам надо сделать - на плечи vfs.Именно, и чем больше я ее туда перекину, тем будет лучше.
>Клиент обязан дождаться когда транзакция закончится, и новая транзакция не откроется до
>тех пор пока не закончена старая? иначе мы имеем очень большое
>окно между тем как мы закрыли транзакцию - и тем как
>она реально закомичена на сервере.Зависит от флагов - можно сделать как sync, так и async транзакцию.
Со второй мы можем потерять данные, т.к. никогда не узнаем, что она завершилась.Сейчас транзакция содержит до 14 (размер pvec) страниц. Можно увеличить (опция монтирования), но VFS не очень дружит, я лениво сделал почти как в write_cache_pages().
Можно создать сколько угодно много транзакций и запустить их параллельно (на сервере они и будут обрабатываться параллельно), но мой опыт работы с ядерными сокетами показывает, что больше чем один поток размером в примерно 64к на 1гбит/с не нужно, т.к. сеть не тянет, поэтому есть одна кэшированная (в смысле не создается все время, а создана статически для сокета) транзакция на сокет, с которой идет бОльшая часть работы. Прием по отношению к ней асинхронен.
Собственно, пока мы с вами беседовали, я доделал механизм транзакций, сейчас начну failover, возможно сегодня/завтра будет, что показать...
>клиент делает statfs - при этом другой клиент пишет (изменяет размер).
>какой размер увидит первый клиент? будет ли повторно запрашиваться атрибуты файлов если
>сделать 2 раза ls -l на каталоге с 100к файлов?Нет, они же кэшируются на клиенте. Если памяти достаточно и иноды не выкинули, в таком случае их придется перечитать. Статистика пока не синхронизируется.
>>Все синхронизации делаются не строже, чем в случае локальной работы нескольких потоков
>>с одним и тем же файлом.
>
>в случае локальной работы - за вас всю синхронизацию делает vfs.
>в случае сетевой работы (при нескольких нодах) - вам это прийдется делать
>за vfs.Я имел ввиду, что pohmelfs сервер делает их не строже, чем VFS для локальных потоков.
Хотя, например direct-io я просто убил на клиенте... Тоже способ, хотя не самый красивый, при необходимости всегда можно вернуть :)
>>это подходит только в случае когда данные находятся на том же сервере
>>что и meta-data.
>>тогда вы перекладываете работу которую вам надо сделать - на плечи vfs.
>
>Именно, и чем больше я ее туда перекину, тем будет лучше.не выйдет. выполнение rpc при захваченых vfs локах будет весело.
>
>>Клиент обязан дождаться когда транзакция закончится, и новая транзакция не откроется до
>>тех пор пока не закончена старая? иначе мы имеем очень большое
>>окно между тем как мы закрыли транзакцию - и тем как
>>она реально закомичена на сервере.
>
>Зависит от флагов - можно сделать как sync, так и async транзакцию.
>
>Со второй мы можем потерять данные, т.к. никогда не узнаем, что она
>завершилась.у люстры async - и данные она не теряет.
>
>
>Можно создать сколько угодно много транзакций и запустить их параллельно (на сервере
>они и будут обрабатываться параллельно), но мой опыт работы с ядерными
>сокетами показывает, что больше чем один поток размером в примерно 64к
>на 1гбит/с не нужно, т.к. сеть не тянет, поэтому есть одна
>кэшированная (в смысле не создается все время, а создана статически для
>сокета) транзакция на сокет, с которой идет бОльшая часть работы. Прием
>по отношению к ней асинхронен.ех. кроме tcp/ip есть другие сети - где все не так печально.
есть TSO, есть network dma и тп.
>
>>клиент делает statfs - при этом другой клиент пишет (изменяет размер).
>>какой размер увидит первый клиент? будет ли повторно запрашиваться атрибуты файлов если
>>сделать 2 раза ls -l на каталоге с 100к файлов?
>
>Нет, они же кэшируются на клиенте. Если памяти достаточно и иноды не
>выкинули, в таком случае их придется перечитать. Статистика пока не синхронизируется.ех.. а как же вы хотите писать? как может второй клиент узнать где для него конец файла что бы записать? он один раз сделал ls -l, получил атрибуты - второй клиент после этого записал в файл и сдвинул EOF.
после этого первый клиент проснулся и решил писать - он что потеряет данные первого?
>не выйдет. выполнение rpc при захваченых vfs локах будет весело.Естественно, что что-то вытаскивается в сервер, плюс fcntl() локи уж очень медленные...
>у люстры async - и данные она не теряет.
Т.е. она не дожидается подтверждения, что данные записаны, прежде, чем освободить страницы? И как же это работает в случае отвала сервера? :)
>ех. кроме tcp/ip есть другие сети - где все не так печально.
Все любят только tcp/ip, даже поверх ib/iwarp/whatever.
Хотя конечно можно и оптимизировать без них.>есть TSO, есть network dma и тп.
Я могу получить доступ к IB-связанным машинам, но пока это не самая приоритетная задача, по понятным причинам незавершенности других вещей :)
Под TSO вы наверное имели ввиду не tcp segmentation offload, а полную загрузку стека в карту - очень криво в подавляющем большинстве случаев, которые я видел (собствено, за это их и не берут в ядро и врядли когда не возьмут), а в остальных есть channel-like интерфейс, который можно легко прицепить к pohmelfs.>ех.. а как же вы хотите писать? как может второй клиент узнать
>где для него конец файла что бы записать? он один раз
>сделал ls -l, получил атрибуты - второй клиент после этого записал
>в файл и сдвинул EOF.
>после этого первый клиент проснулся и решил писать - он что потеряет
>данные первого?Надеюсь, что вы не пишете такой код... Задайте тот же самый вопрос, если у вас два потока, один делает lseek(), а второй просто write(). И тоже самое будет с двумя клиентами pohmelfs.
>>не выйдет. выполнение rpc при захваченых vfs локах будет весело.
>
>Естественно, что что-то вытаскивается в сервер, плюс fcntl() локи уж очень медленные...
>то есть разговора о производительности метаданных не идет ?
для решения вопросов о локах - у люстры свой lockd, это один из самых обольших ее кусков.
>
>>у люстры async - и данные она не теряет.
>
>Т.е. она не дожидается подтверждения, что данные записаны, прежде, чем освободить страницы?так же как и при журналировании данных.
>И как же это работает в случае отвала сервера? :)есть много механизмов - replay журнала один из них.
>
>>ех. кроме tcp/ip есть другие сети - где все не так печально.
>
>Все любят только tcp/ip, даже поверх ib/iwarp/whatever.
>Хотя конечно можно и оптимизировать без них.cray/hp/ibm - не любят tcp, и используют его только как service channel.
>[оверквотинг удален]
>>есть TSO, есть network dma и тп.
>
>Я могу получить доступ к IB-связанным машинам, но пока это не самая
>приоритетная задача, по понятным причинам незавершенности других вещей :)
>Под TSO вы наверное имели ввиду не tcp segmentation offload, а полную
>загрузку стека в карту - очень криво в подавляющем большинстве случаев,
>которые я видел (собствено, за это их и не берут в
>ядро и врядли когда не возьмут), а в остальных есть channel-like
>интерфейс, который можно легко прицепить к pohmelfs.
>network dma - это в основном у IB и подобных карт, правда патчи для этого не принимаются в ядро - но позволяют передавать минуя стек. Это один из кусков патчей в люстре.
tso - в сочетании с zero copy sockets - это network dma для бедных. указали большой буфер, а сетевуха сама порежет на пакеты и плюнет в получателя.
>>ех.. а как же вы хотите писать? как может второй клиент узнать
>>где для него конец файла что бы записать? он один раз
>>сделал ls -l, получил атрибуты - второй клиент после этого записал
>>в файл и сдвинул EOF.
>>после этого первый клиент проснулся и решил писать - он что потеряет
>>данные первого?
>
>Надеюсь, что вы не пишете такой код... Задайте тот же самый вопрос,
>если у вас два потока, один делает lseek(), а второй просто
>write(). И тоже самое будет с двумя клиентами pohmelfs.судя по вашим словам "статистика не сихнронизиуется" - первый клиент будет иметь i_size = size_old, от первого ls -l (выполнен stat), и будет писать ровно с этой позиции - оно закэшировано в его vfs стеке.
второй клиент i_size уже обновил - и писать надо с другой позиции - но без когерентности meta-data - как первый клиент узнает что размер обновился? кто за него сделает этот lseek?
>то есть разговора о производительности метаданных не идет ?
>для решения вопросов о локах - у люстры свой lockd, это один
>из самых обольших ее кусков.Из чего вы сделали такой вывод о производительности метаданных?
>так же как и при журналировании данных.
Ога, а кто дожидется, что запись в журнал завершена :)
>tso - в сочетании с zero copy sockets - это network dma
>для бедных. указали большой буфер, а сетевуха сама порежет на пакеты
>и плюнет в получателя.tso прозрачно для сокетного интерфейса - если поддерживается картой, то стек об этом позаботится и создат большуй skb, в противном случае побъет на mss/mtu.
>>Надеюсь, что вы не пишете такой код... Задайте тот же самый вопрос,
>>если у вас два потока, один делает lseek(), а второй просто
>>write(). И тоже самое будет с двумя клиентами pohmelfs.
>
>судя по вашим словам "статистика не сихнронизиуется" - первый клиент будет иметьСтатистика _пока_ не синхронизируется, это раз.
>i_size = size_old, от первого ls -l (выполнен stat), и будет
>писать ровно с этой позиции - оно закэшировано в его vfs
>стеке.
>
>второй клиент i_size уже обновил - и писать надо с другой позиции
>- но без когерентности meta-data - как первый клиент узнает
>что размер обновился? кто за него сделает этот lseek?Вы разве не видите огромный race в этом случае для локального VFS и двух потоков?
Прямо один в один, только потоки локальные. Что будет, если один собрался делать write(), а второй lseek()?Так банально _НЕЛЬЗЯ_ делать, если вы заботитесь о сохранности данных, т.к. другой поток может вызвать lseek() и переписать указатель, откуда надо делать write(). Для этого и изобрели pwrite() и остальных (собственно, они и используются в pohmelfs server).
Еще раз повторю, что pohmelfs не будет поддерживать синзхронизацию более строгую, чем локальный VFS.
>
>>то есть разговора о производительности метаданных не идет ?
>>для решения вопросов о локах - у люстры свой lockd, это один
>>из самых обольших ее кусков.
>
>Из чего вы сделали такой вывод о производительности метаданных?хотя бы из ваших слов о fcntl lock - что они не быстрые, есть такая буква.
И о структуре транзакций.>
>>так же как и при журналировании данных.
>
>Ога, а кто дожидется, что запись в журнал завершена :)клиент - для этого есть средства. в Lustre book об этом была помоему глава.
>
>>>Надеюсь, что вы не пишете такой код... Задайте тот же самый вопрос,
>>>если у вас два потока, один делает lseek(), а второй просто
>>>write(). И тоже самое будет с двумя клиентами pohmelfs.
>>
>>судя по вашим словам "статистика не сихнронизиуется" - первый клиент будет иметь
>
>Статистика _пока_ не синхронизируется, это раз.но ведь это уже названо релизом? скажите что это глубокая альфа - я оставлю свои коментарии :) или что я об этом не думал.
>[оверквотинг удален]
>>i_size = size_old, от первого ls -l (выполнен stat), и будет
>>писать ровно с этой позиции - оно закэшировано в его vfs
>>стеке.
>>
>>второй клиент i_size уже обновил - и писать надо с другой позиции
>>- но без когерентности meta-data - как первый клиент узнает
>>что размер обновился? кто за него сделает этот lseek?
>
>Вы разве не видите огромный 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 ?>Прямо один в один, только потоки локальные. Что будет, если один собрался
>делать write(), а второй lseek()?
>
>Так банально _НЕЛЬЗЯ_ делать, если вы заботитесь о сохранности данных, т.к. другой
>поток может вызвать lseek() и переписать указатель, откуда надо делать write().
>Для этого и изобрели pwrite() и остальных (собственно, они и используются
>в pohmelfs server).в случае люстры - 2 клиента могут писать в EOF последовательно и это будет работать.
у вас это запрещено - ок, запишем.
Есть еще MPI - где это не запрещено, макс захотят что бы стояли барьеры.
>
>Еще раз повторю, что pohmelfs не будет поддерживать синзхронизацию более строгую, чем
>локальный VFS.дай бог что бы она поддерживала хотя бы такую как есть в локальном VFS, пока и ее нету.
Я лиш пытаюсь показать подводные камни на этом пути, да и немного - не совсем привычных use case которые тем немеение существуют.
>>Из чего вы сделали такой вывод о производительности метаданных?
>
>хотя бы из ваших слов о 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 которые тем немеение существуют.Нет, вы пытаетесь показать, что это не удастся. Но вы не правы :)
Это не ядерная физика, так что сложного в этом нет ничего, просто нужно немного больше двух месяцев, но вы очень не хотите сравнить развитие любой другой ФС за это время.
>Нет, вы пытаетесь показать, что это не удастся. Но вы не правы
>:)
>Это не ядерная физика, так что сложного в этом нет ничего, просто
>нужно немного больше двух месяцев, но вы очень не хотите сравнить
>развитие любой другой ФС за это время.Почитал, что из себя представляла Lustre в конце 2003 года... И эти люди запрещают мне ковыряться в носу.
Удачи.
>[оверквотинг удален]
>>Еще раз подчеркиваю
>>клиент1: statfs inode, open(O_APPEND); sleep
>>клиент2: open(,O_APPEND); write, exit;
>>клиент1: write, exit
>>по времени эти 2 действия не пересекаются - только i_size обновляется асинхронно.
>>
>>такая последовательность действий запрещена с точки зрения pohmelfs ?
>
>Печально... Запустите этот код параллельно в двух потоках, только в один из
>них добавьте lseek().причем тут lseek?
>[оверквотинг удален]
>>>поток может вызвать lseek() и переписать указатель, откуда надо делать write().
>>>Для этого и изобрели pwrite() и остальных (собственно, они и используются
>>>в pohmelfs server).
>>
>>в случае люстры - 2 клиента могут писать в EOF последовательно и
>>это будет работать.
>>у вас это запрещено - ок, запишем.
>
>Вы не видите ошибки в этом коде, печально... sys_write() работает со смещением,
>а не с размером иноды.ээ.. можно уточнить в каком из ядер вдруг появилось смещение?
asmlinkage ssize_t sys_write(unsigned int fd, const char __user * buf, size_t count)
из 2.6.24.Пишется буфер, позиция берется из f_pos, которая на момент open(,O_APPEND) берется из i_size - все согластно POSIX.
>
>Тем не менее обновление метаданных работает совершенно по тому же самому механизму,
>что и инвалидация страниц. Это я про i_size, права доступа, uig/gid
>(наверное нужно atime) и т.п. Собственно для этого есть структура, сильно
>напоминающая ту, что заполняет stat(2).хотел бы я посмотреть на rpc трафик в этом случае. ну да лана.
>[оверквотинг удален]
>>дай бог что бы она поддерживала хотя бы такую как есть в
>>локальном VFS, пока и ее нету.
>
>Я так полагаю, вы в этом сомневаетесь :)
>
>>Я лиш пытаюсь показать подводные камни на этом пути, да и немного
>>- не совсем привычных use case которые тем немеение существуют.
>
>Нет, вы пытаетесь показать, что это не удастся. Но вы не правы
>:)да ну? я лиш показал некоторые use case на которые надо обратить внимание :)
и которые в текущей реализации сделаны "никак".
>причем тут lseek?При том, что если два потока не синхронизированы, запись может происходить вообще в любое место файла. А с учетом того, что обновление 64битной переменной не атомарно (f_pos) на 32битной архитектуре, то при запуске этого приложения например в gdb (или при ptrace'инге) там может быть значение наполовину их одного потока, а наполовину из другого.
>Пишется буфер, позиция берется из f_pos, которая на момент open(,O_APPEND) берется из
>i_size - все согластно POSIX.И только в этом случае f_pos устанавливается под i_mutex'ом.
Это я к тому, что вы в любом случае должны (кроме как для O_APPEND) синхронизировать запись в файл между двумя потоками, и это не задача VFS или файловой системы следить за атомарностью записи.
Кстати, пока я писал этот ответ, подумал, что проще передавать O_APPEND в транзакции (там есть open intent, где сейчас передается только O_RDWR/O_RDONLY). Нужно поэкспериментировать.
>хотел бы я посмотреть на rpc трафик в этом случае. ну да
>лана.Вы показываете случай, в котором все сетевые файловые системы будут иметь серьезную нагрузку системных сообщений, при этом делаете акцент, что в pohmelfs будет большое их количество. Надо полагать, у вас есть какая-то причина быть необъективным :)
Кстати, механизм когерентности кэшей выполняется не как RPC, сервер сам рассылает сообщения об обновлениях/инвалидации.
>>причем тут lseek?
>
>При том, что если два потока не синхронизированы, запись может происходить вообще
>в любое место файла. А с учетом того, что обновление 64битной
>переменной не атомарно (f_pos) на 32битной архитектуре, то при запуске этого
>приложения например в gdb (или при ptrace'инге) там может быть значение
>наполовину их одного потока, а наполовину из другого.для этого делаются блокировки.
>
>>Пишется буфер, позиция берется из f_pos, которая на момент open(,O_APPEND) берется из
>>i_size - все согластно POSIX.
>
>И только в этом случае f_pos устанавливается под i_mutex'ом.или под dlm локингом.
>
>Это я к тому, что вы в любом случае должны (кроме как
>для O_APPEND) синхронизировать запись в файл между двумя потоками, и это
>не задача VFS или файловой системы следить за атомарностью записи.ну ну.. у каждого свое виденье - лиш бы это не приводило к data corruption :)
>[оверквотинг удален]
>транзакции (там есть open intent, где сейчас передается только O_RDWR/O_RDONLY). Нужно
>поэкспериментировать.
>
>>хотел бы я посмотреть на rpc трафик в этом случае. ну да
>>лана.
>
>Вы показываете случай, в котором все сетевые файловые системы будут иметь серьезную
>нагрузку системных сообщений, при этом делаете акцент, что в pohmelfs будет
>большое их количество. Надо полагать, у вас есть какая-то причина быть
>необъективным :)я лиш перевернул пример который был изначально дан для люстры. За одно показал к чему приводит нежелание синхронизировать meta-data между нодами.
>
>Кстати, механизм когерентности кэшей выполняется не как RPC, сервер сам рассылает сообщения
>об обновлениях/инвалидации.RPC - remote procedure call. любое сообщение по которому получатель должен выполнить некоторое действие - во всяком случае в обычном контексте.
>RPC - remote procedure call. любое сообщение по которому получатель должен выполнить
>некоторое действие - во всяком случае в обычном контексте.Я всегда считал, что RPC вызывает клиент, а выполняет сервер. Впрочем, вероятно любые команды можно рассматривать как удаленный вызов каких-то функций.
>>RPC - remote procedure call. любое сообщение по которому получатель должен выполнить
>>некоторое действие - во всяком случае в обычном контексте.
>
>Я всегда считал, что RPC вызывает клиент, а выполняет сервер. Впрочем, вероятно
>любые команды можно рассматривать как удаленный вызов каких-то функций.проще говорить отправитель/получатель - тогда нет путаницы с сервер/клиент.
>>>:) не совсем так, при бОльших массивах слив в разы.
>>
>>да ну? у вас сведения более точные чем внутренние тесты Sun?
>
>Насколько я помню, это именно я их привел в треде, хотя да,
>из рассылки lustre.
>Тесты ноября 2007?Нет, конец зимы в этом году - или даже месяц назад.. не помню.
>[оверквотинг удален]
>>возьмите листок бумаги.. нарисуйте структуру FS по уровням.
>>начиная с аллокации блоков, и заканчивая директориями/файлами поверх стораджа.
>>zfs (хоть zfs-fuse) это самый высокий уровень, люстре столько не надо.
>>ей нужны более низко уровеневые веши - уровень стораджа с транзакциями.
>>можно понять что это 2 паралельных ветки - dmu + some directroy structure => zfs и модуль для работы с готовой zfs через fuse-api, fuse-zfs.
>>и вторая ветка dmu+OSS/MDS (uOSS/uMDS) - которая используется для lustre.
>
>Не важно, что lustre не нужен такой высокий уровень абстракции, как может
>предоставить zfs-fuse, может быть от нее возмут только часть, может быть
>все, мы этого не знаем.от кого? от zfs-fuse? как можно взять от модуля интерфейса между zfs и fuse - что-то чего там нету ? ;) Может Вы и не знаете - но те кто разрабатывают это, знают - что откуда берется :)
>>Не важно, что lustre не нужен такой высокий уровень абстракции, как может
>>предоставить zfs-fuse, может быть от нее возмут только часть, может быть
>>все, мы этого не знаем.
>
>от кого? от zfs-fuse? как можно взять от модуля интерфейса между zfs
>и fuse - что-то чего там нету ? ;) Может Вы
>и не знаете - но те кто разрабатывают это, знают -
>что откуда берется :)Полагаю, что для этого и есть zfs-fuse разработчик в штате sun :)
>[оверквотинг удален]
>>>предоставить zfs-fuse, может быть от нее возмут только часть, может быть
>>>все, мы этого не знаем.
>>
>>от кого? от zfs-fuse? как можно взять от модуля интерфейса между zfs
>>и fuse - что-то чего там нету ? ;) Может Вы
>>и не знаете - но те кто разрабатывают это, знают -
>>что откуда берется :)
>
>Полагаю, что для этого и есть zfs-fuse разработчик в штате sun :)
>вы ошибаетесь, делаете ложные предположения, и пытаетесь отстаивать свои илюзии.
Увы тут я ничем не могу помочь.http://wiki.lustre.org/index.php?title=Lustre_OSS/MDS_with_Z...
если вы тут найте слово fuse, я вам доставлю ящик пива куда скажете.
Вот это реальность - а не ваши "предположения".
Которые отстают от действительности - как земля от луны.
>http://wiki.lustre.org/index.php?title=Lustre_OSS/MDS_with_Z...
>если вы тут найте слово fuse, я вам доставлю ящик пива куда
>скажете.
>Вот это реальность - а не ваши "предположения".
>Которые отстают от действительности - как земля от луны.Кстати, из вашей ссылки (не в продолжение флейма, уже надоело, нам вряд-ли переубедить друг друга):
hg clone http://www.wizy.org/mercurial/zfs-lustre
Вот там (в исходниках, changelog и т.д.) очень много слов fuse-zfs :)
>а. забыл добавить GPLv2. что бы не говорили о закрытостиhttp://wiki.lustre.org/index.php?title=Contribution_Policy
No way. Как разработчик, я не хочу отдавать права на свой код кому-то еще, кто будет использовать мой код бесплатно и менять лицензию и т.п.
>Мисье забыл слово Lustre? честный posix API - уже существующие транзакции и
>блокировки, уже работает на машинках из списка Top10.
>таки видимо забыли ;)А прочитать еще пару строчек не смогли? Там написано про Lustre :)
Враньё, только на днях пробовал http://www.gluster.org, и смотрел http://www.pvfs.org.
>Враньё, только на днях пробовал http://www.gluster.org, и смотрел http://www.pvfs.org.Если в ваших тестах не обнаружились, это не означает, что их нет. Достаточно одного падения, чтобы понять, что код содержит ошибки, несколько успешных запусков не говорят о работоспособности в целом.
>>Враньё, только на днях пробовал http://www.gluster.org, и смотрел http://www.pvfs.org.
>
>Если в ваших тестах не обнаружились, это не означает, что их нет.
>Достаточно одного падения, чтобы понять, что код содержит ошибки, несколько успешных
>запусков не говорят о работоспособности в целом.Я про это!
>>что-то я отстал от жизни - подобных открытых ФС уже вроде есть
>>несколько штук, или нет?
>Вообще-то ни одной.
>Я про это!
>
>>>что-то я отстал от жизни - подобных открытых ФС уже вроде есть
>>>несколько штук, или нет?
>>Вообще-то ни одной.А, ясно. Такие системы конечно же есть, но все они обладают рядом недостатков, с моей точки зрения, достаточно серьезных, зачастую неустранимых, некоторые я описал здесь, другие раньше : https://www.opennet.ru/opennews/art.shtml?num=12559
Если устраивает существующий вариант, то вам ничего менять не нужно.
Народ, поясните, что предпочтительнее в случае "распределённой параллельной обработки данных", работать с файлами или с некоторой базой данных?
Мне кажется, файлы будут дороже. Да?
>Народ, поясните, что предпочтительнее в случае "распределённой параллельной обработки данных", работать с
>файлами или с некоторой базой данных?
>Мне кажется, файлы будут дороже. Да?Никакая база данных не умеет быстро работать с блобами.
Распределенность и параллельность в этом вопросе вообще не понятно для чего.
А по сути, что база данных, что файловая система, это одно и тоже, только метод доступа разный. Для одних целей удобно одно, для других - другое.
>Никакая база данных не умеет быстро работать с блобами.В случае параллельной обработки с блобами вообще вряд ли кто быстро сможет, разве что по чтению, но по чтению и база сможет. К тому же "распределенный" блоб - эта какая же есть нужна?
>Распределенность и параллельность в этом вопросе вообще не понятно для чего.
Вот пытаюсь прояснить для себя.
>А по сути, что база данных, что файловая система, это одно и
>тоже, только метод доступа разный. Для одних целей удобно одно, для
>других - другое.Метод даже очень разный, особенно для совместной работы.
Признаюсь, "файловая система" в данном контексте для меня вещь туманная.
>>Никакая база данных не умеет быстро работать с блобами.
>
>В случае параллельной обработки с блобами вообще вряд ли кто быстро сможет,
>разве что по чтению, но по чтению и база сможет. К
>тому же "распределенный" блоб - эта какая же есть нужна?Файловая система работает с блобами несравнимо лучше, чем любая существующая база данных.
Собственно, файловая система и есть база данных, индексированная по имени объека, с очень оптимальным поиском по ключу и форматом хранения. Без костылей такой метод доступа не позволяет делать поиск по какому-нибудь еще ключу (крому как проверку каждого элемента).
Параллельный доступ к данным файлов осуществляется на уровне VFS, где в Linux блокировки введены очень оптимально (для чтения так вообще нет). Блокировки самой файловой системы согут отличаться (особенно при работе с метаданными), тут уже нужно смотреть дизайн ФС.
>>Распределенность и параллельность в этом вопросе вообще не понятно для чего.Моя личная заинтересованность в такой системе - я бы захотел её использовать для объединения сотни машин, находящихся на линиях с разной пропускной способностью. Т.е. от 10 мегабит до 256К. А здесь, как раз и параллельность и распределенность была бы очень.
>
>Никакая база данных не умеет быстро работать с блобами.
>BerkeleyDB умеет
>>
>>Никакая база данных не умеет быстро работать с блобами.
>>
>
>BerkeleyDB умеетона же хранит данные в файлах, а объединение большого количества блобов в один бОльший не может быть оптимально на файловой системе, не предназначенной для такой работы.
Так что path lookup получается всяко быстрее.
>Народ, поясните, что предпочтительнее в случае "распределённой параллельной обработки данных", работать с
>файлами или с некоторой базой данных?
>Мне кажется, файлы будут дороже. Да?посмотри список на top500.org там про субд ничего нет ибо на HPC кластерах они не используются
Слишком длинное название для успешной раскрутки - нужно сократить до POHFS
>Слишком длинное название для успешной раскрутки - нужно сократить до POHFS"POH." в 16-тиричном виде возвращается в статистике.
Евгений, а насчет аутентификации, что планируется? Будет gssapi? Когда планируете вывести ФС на продакшн статус? Будете ли делать fuse клиента?
Название конечно прикольное : ) Но хочется надеяться, что я буду использовать эту фс взамен ядерному nfs. Звучит описание весьма неплохо.
>Евгений, а насчет аутентификации, что планируется? Будет gssapi? Когда планируете вывести ФС
>на продакшн статус? Будете ли делать fuse клиента?
>Название конечно прикольное : ) Но хочется надеяться, что я буду использовать
>эту фс взамен ядерному nfs. Звучит описание весьма неплохо.FUSE не будет, т.к. написан родной ядерный клиент, в новости не совсем корректно указано, что и клиент, и сервер в userspace. Нужно много тестирования, у меня есть соответствующая база, так что переход из сильно экспериментального состояния не за горами.
Сначала аутентификация будет попроще - секретный ключ на клиенте и сервере, HMAC сообщения, не знаю, нужно ли ее усложнять...
>FUSE не будет, т.к. написан родной ядерный клиент, в новости не совсем
>корректно указано, что и клиент, и сервер в userspace. Нужно много
>тестирования, у меня есть соответствующая база, так что переход из сильно
>экспериментального состояния не за горами.
>Сначала аутентификация будет попроще - секретный ключ на клиенте и сервере, HMAC
>сообщения, не знаю, нужно ли ее усложнять...Жалко, кластерных фс много, а толковой и допиленой типа nfs/samba нет. Безальтернативно получается.
>>FUSE не будет, т.к. написан родной ядерный клиент, в новости не совсем
>>корректно указано, что и клиент, и сервер в userspace. Нужно много
>>тестирования, у меня есть соответствующая база, так что переход из сильно
>>экспериментального состояния не за горами.
>>Сначала аутентификация будет попроще - секретный ключ на клиенте и сервере, HMAC
>>сообщения, не знаю, нужно ли ее усложнять...
>
>Жалко, кластерных фс много, а толковой и допиленой типа nfs/samba нет. Безальтернативно
>получается.Так зачем FUSE, когда есть ядерный клиент? Или вы о другом?
>Так зачем FUSE, когда есть ядерный клиент? Или вы о другом?Да ну суть в том, что nfs сейчас поддерживает gssapi, а вы вроде как и не планируете : )
Ну и вообще - вы же решили двигаться в сторону кластерной фс.
Кстати для кластера GSSAPI тоже было бы неплохим решением - получаете автоматически поддержку шифрования, да и вообще разом снимаете себе головную боль изобретением криптографических велосипедов - все продумано уже как много лет.
>- Поддержание локального кэша для данных и мета-данных, согласованного для всех
>узлов использующих ФС;lustre
>- Обработка данных и событий в асинхронном режиме, за исключением операций
>с жёсткими и символическими ссылками;lustre, все в асинхронном режиме - кроме блокировок.
>- Гибкая архитектура, оптимизированная для обмена данных по сети, включая возможность
>объединения нескольких операций в одну управляющую команду переда...lustre, собственно код cmd3 уже позволяет держать несколько серверов метаданных (пока только 32 - но небольшой патчик может увеличить это число до нужных приделов)
Это не кластерная фс, это замена nfs, как я вывожу из описания. Хватит уже с люстрой своей.
>Это не кластерная фс, это замена nfs, как я вывожу из описания.
>Хватит уже с люстрой своей.Замена NFS это в текущем состоянии, задумка была на создание открытой и функциональной распределенной система, что-то вроде GPFS от IBM в первую очередь.
>lustre, собственно код cmd3 уже позволяет держать несколько серверов метаданных (пока только
>32 - но небольшой патчик может увеличить это число до нужных
>приделов)Я не слежу за Lustrу уже давно, но вы не путаете количество серверов метаданных с избыточностью этих серверов? Один метадата сервер всегда был узким местом Lustre, и именно с ним собирались бороться увеличением количества серверов метаданных. Но при падении одного сейчас есть master/slave репликация, slave сервер может быть только один.
Впрочем, это было давно, может быть сейчас уже все лучше...Lustre очень сильно портит (улучшает, не важно, пусть будет "меняет") меняет ext*, эти изменения зачастую далеки от идеала. А что Lustre делает с VFS?
Это очень сложная система, с огромным набором костылей и подпорок как к файловой системе, так и VFS. Она трудна в установке и администрировании. Строгая привязка к ядру. Из-за всех этих проблем (или наоборот радикальных улучшений, хотя вряд ли) ее и не стали принимать в ядро.Плюс ее переход на FUSE...
>>lustre, собственно код cmd3 уже позволяет держать несколько серверов метаданных (пока только
>>32 - но небольшой патчик может увеличить это число до нужных
>>приделов)
>
>Я не слежу за Lustrу уже давно, но вы не путаете количество
>серверов метаданных с избыточностью этих серверов? Один метадата сервер всегда был
>узким местом Lustre, и именно с ним собирались бороться увеличением количества
>серверов метаданных. Но при падении одного сейчас есть master/slave репликация, slave
>сервер может быть только один.
>Впрочем, это было давно, может быть сейчас уже все лучше...Не путаю. а вы очень давно смотрели люстру. как в failover узлов может быть больше 1го, так и metadata серверов может быть больше 1го. 32 в текущей реализации - и одна директория может быть расположена на разных mds серверах.
>
>Lustre очень сильно портит (улучшает, не важно, пусть будет "меняет") меняет ext*,
>эти изменения зачастую далеки от идеала. А что Lustre делает с
>VFS?
>Это очень сложная система, с огромным набором костылей и подпорок как к
>файловой системе, так и VFS. Она трудна в установке и администрировании.
>Строгая привязка к ядру. Из-за всех этих проблем (или наоборот радикальных
>улучшений, хотя вряд ли) ее и не стали принимать в ядро.вы что курили? собрать клиента можно без хака ядра.
>
>
>Плюс ее переход на FUSE...Вы что курили о переходе на FUSE? дайте туже траву ;)
и того - 2/3 лож и дезинформация :)
>Не путаю. а вы очень давно смотрели люстру. как в failover узлов
>может быть больше 1го, так и metadata серверов может быть больше
>1го. 32 в текущей реализации - и одна директория может быть
>расположена на разных mds серверах.Да, целых два метадата сервера - састер и реплика. А затем несколько таких пар для параллельного доступа. Но нет нескольких реплик одного и того же мастера?
>>Это очень сложная система, с огромным набором костылей и подпорок как к
>>файловой системе, так и VFS. Она трудна в установке и администрировании.
>>Строгая привязка к ядру. Из-за всех этих проблем (или наоборот радикальных
>>улучшений, хотя вряд ли) ее и не стали принимать в ядро.
>
>вы что курили? собрать клиента можно без хака ядра.Да кому этот клиент нужен? вы сервер видели? Хотя бы размер патча для ext* только.
Именно с ним проблемы.>>Плюс ее переход на FUSE...
>
>Вы что курили о переходе на FUSE? дайте туже траву ;)
>
>и того - 2/3 лож и дезинформация :)Lustre 1.8 is planned for next summer and will introduce user space servers for both Linux and Solaris, running with ZFS/DMU. We'll continue to support the existing in-kernel servers for Linux with ext3 until Lustre 2.0 at the end of the calendar year. In 2.0 we'll release clustered metadata servers, enabling the same kind of scalability for metadata that we have for storage servers today. And, although it will also mark the end of in-kernel servers and ext3, Linux will remain strategic to the future of Lustre.
http://www.sun.com/aboutsun/media/features/qa_cfs.jsp
Вы совершенно не в теме.
Лана - ответим более развернуто.>
>Lustre очень сильно портит (улучшает, не важно, пусть будет "меняет") меняет ext*,
>эти изменения зачастую далеки от идеала.Аха.. тота их с радостью принимают в ext4..
А что Lustre делает с
>VFS?ничего не делает. по сути очень простой патч - который позволяет форсировать вызов invalidate для dentry. openintent реализованый (хоть сколько-то нормально) в 2.6.12 and up - подобие lookup intent из lustre, который может подсказать FS что будет следующей операцией и этим съэкономить дорогой rpc.
>Это очень сложная система, с огромным набором костылей и подпорок как к
>файловой системе, так и VFS.Ошибаетесь.
> Она трудна в установке и администрировании.
вы что курили? или смотрели что-то очень дремучее.. lctl $param это уже сложно...
>Строгая привязка к ядру.Ошибаетесь - patchless клиент работает на всем от 2.6.16 до 2.6.24 + rhel4, sles9.
> Из-за всех этих проблем (или наоборот радикальных
>улучшений, хотя вряд ли) ее и не стали принимать в ядро.да да, и это не мешало это в конечном счете реализовывать все что требуется - хоть и медленно и для других fs.
>
>
>Плюс ее переход на FUSE...ну на счет этого мы уже говорил - вы что курили уважаемый. если вы о zfs - то смею огорчить - читать анонсы надо внимательнее - статическую линковку с libzpool не отменяли.
Lustre никогда не будет использовать FUSE, исключение - мой собственный fuse client по большей части для тестирования порта на FreeBSD.
>Аха.. тота их с радостью принимают в ext4..Не принимают. Они уже и слать перестали (очень давно кстати).
> А что Lustre делает с
>>VFS?
>
>ничего не делает. по сути очень простой патч - который позволяет форсировать
>вызов invalidate для dentry. openintent реализованый (хоть сколько-то нормально) в 2.6.12
>and up - подобие lookup intent из lustre, который может подсказать
>FS что будет следующей операцией и этим съэкономить дорогой rpc.Повнимательнее изучите...
>>Строгая привязка к ядру.
>
>Ошибаетесь - patchless клиент работает на всем от 2.6.16 до 2.6.24 +
>rhel4, sles9.А вы сервер пробовали?
Когда только вышел последний 1.5 для 2.6.9 насколько я помню, после него еще куча ядер вышла без поддержки от Lustre.>> Из-за всех этих проблем (или наоборот радикальных
>>улучшений, хотя вряд ли) ее и не стали принимать в ядро.
>
>да да, и это не мешало это в конечном счете реализовывать все
>что требуется - хоть и медленно и для других fs.Тем не менее Lustre не в ядре и там никогда не будет.
>>Плюс ее переход на FUSE...
>
>ну на счет этого мы уже говорил - вы что курили уважаемый.
>если вы о zfs - то смею огорчить - читать анонсы
>надо внимательнее - статическую линковку с libzpool не отменяли.
>Lustre никогда не будет использовать FUSE, исключение - мой собственный fuse client
>по большей части для тестирования порта на FreeBSD.http://www.sun.com/aboutsun/media/features/qa_cfs.jsp
Почитайте на досуге. Lustre переходит полностью на FUSE с версии 2.0 из-за того, что огромное количество патчей для ext* им трудно поддерживать.
>>Аха.. тота их с радостью принимают в ext4..
>
>Не принимают. Они уже и слать перестали (очень давно кстати).LOL! пейсши есшо. в 2.6.24 или (.25) - приняли multiblock allocator который писали с CFS.
приняли фиксы raid5 и тп.
читайте доки они рулез.
http://lwn.net/Articles/203915/
считаем количество вхождений слова CFS.
http://lkml.org/lkml/2008/1/29/22
вот еще ссылочка
там на втором месте идет фамилия
Alex Tomas -> CFS.
Girish Shilamkar -> помоему тоже CFS.Так что плиз сначала ознакомьтесь с Changelog и тп.
>
>> А что Lustre делает с
>>>VFS?
>>
>>ничего не делает. по сути очень простой патч - который позволяет форсировать
>>вызов invalidate для dentry. openintent реализованый (хоть сколько-то нормально) в 2.6.12
>>and up - подобие lookup intent из lustre, который может подсказать
>>FS что будет следующей операцией и этим съэкономить дорогой rpc.
>
>Повнимательнее изучите...Вы не поверите - я это не только изучал, но и фиксил люстру чтобы она ровнее работала с vfs. Так что как люстра работает - я в курсе.
>
>>>Строгая привязка к ядру.
>>
>>Ошибаетесь - patchless клиент работает на всем от 2.6.16 до 2.6.24 +
>>rhel4, sles9.
>
>А вы сервер пробовали?
>Когда только вышел последний 1.5 для 2.6.9 насколько я помню, после него
>еще куча ядер вышла без поддержки от Lustre.а зачем сервер без поддержки вещей которые нужны люстре? да и по сути не так уж много надо. Опять же - смотрим внимательно последние pach-series для люстры - что видим - 80% патчей - добаляют экспорты из ядра. Так что вам стоит ознакомиться детальнее с тем что говорите.
>
>>> Из-за всех этих проблем (или наоборот радикальных
>>>улучшений, хотя вряд ли) ее и не стали принимать в ядро.
>>
>>да да, и это не мешало это в конечном счете реализовывать все
>>что требуется - хоть и медленно и для других fs.
>
>Тем не менее Lustre не в ядре и там никогда не будет.
>Гониш ;) open intent таки в ядре - в принципе вполне устраивает - хотя видимо это на извращенный вкус господ из fs-devel - рулезно делать open из revalidate, а потом подхватывать открытый file.
Изврат, но и так жить можно.
>[оверквотинг удален]
>>ну на счет этого мы уже говорил - вы что курили уважаемый.
>>если вы о zfs - то смею огорчить - читать анонсы
>>надо внимательнее - статическую линковку с libzpool не отменяли.
>>Lustre никогда не будет использовать FUSE, исключение - мой собственный fuse client
>>по большей части для тестирования порта на FreeBSD.
>
>http://www.sun.com/aboutsun/media/features/qa_cfs.jsp
>
>Почитайте на досуге. Lustre переходит полностью на FUSE с версии 2.0 из-за
>того, что огромное количество патчей для ext* им трудно поддерживать.Мне достаточно что я участвую в разработке Люстры :) поэтому читать ваш бред (вы уж извинете меня - я чуть лучше знаю что внутри) - смешно.
Вы не компетентны в люстре - и собственно по этому ссылку на ваш блог с размышлениями о люстре - вычеркнули из opennet.
посоветую читать что-то большее чем about sun и додумывать того чего там нету.
к примеру ARCH wiki - http://arch.lustre.org/index.php?title=Architecture_ZFS_for_...
Поэтому выдавать ваши измышления о использовании FUSE за действительность - не стоит.
Fuse нет, небыло и не будет в люстре - может быть на клиенте - и то для моих эксперементов.
>Так что плиз сначала ознакомьтесь с Changelog и тп.Смешно. А слово swsoft например встречается еще чаще.
При этом там не только контейнерная часть. Не сомневаюсь, что команда lustre/clusterfs фиксит баги, и эти патчи принимают в ядро.>>Когда только вышел последний 1.5 для 2.6.9 насколько я помню, после него
>>еще куча ядер вышла без поддержки от Lustre.
>
>а зачем сервер без поддержки вещей которые нужны люстре? да и по
>сути не так уж много надо. Опять же - смотрим внимательно
>последние pach-series для люстры - что видим - 80% патчей -
>добаляют экспорты из ядра. Так что вам стоит ознакомиться детальнее с
>тем что говорите.Не уходите от темы. напомню, что она звучит так: lustr содержит огромную кодовую базу, которую не принимают и не будут принимать в ядро. Не считая исправления ошибок (и возможно расширения функционала ext*, которое подходит для общего использования) Код сервера огромен и выпускался (выпускается до сих пор?) только для конкретной версии ядра.
>Гониш ;) open intent таки в ядре - в принципе вполне устраивает
>- хотя видимо это на извращенный вкус господ из fs-devel -
>рулезно делать open из revalidate, а потом подхватывать открытый file.
>Изврат, но и так жить можно.Единственное расширение из Lustre. И то про эти интенты говорят жу бог знает сколько, не думаю, что этого не было в xfs.
>>http://www.sun.com/aboutsun/media/features/qa_cfs.jsp
>
>Мне достаточно что я участвую в разработке Люстры :) поэтому читать ваш
>бред (вы уж извинете меня - я чуть лучше знаю что
>внутри) - смешно.Процитирую, вы не ослили предпоследний параграф:
Lustre 1.8 is planned for next summer and will introduce user space servers for both Linux and Solaris, running with ZFS/DMU. We'll continue to support the existing in-kernel servers for Linux with ext3 until Lustre 2.0 at the end of the calendar year. In 2.0 we'll release clustered metadata servers, enabling the same kind of scalability for metadata that we have for storage servers today. And, although it will also mark the end of in-kernel servers and ext3, Linux will remain strategic to the future of Lustre.
>Вы не компетентны в люстре - и собственно по этому ссылку на
>ваш блог с размышлениями о люстре - вычеркнули из opennet.Понятия не имею, что было или не было на opennet, тем не менее из моих знаний о старой (еще 1.5) lustre похоже ничего не поменялось... Хотя конечно процесс идет.
>посоветую читать что-то большее чем about sun и додумывать того чего там
>нету.
>к примеру ARCH wiki - http://arch.lustre.org/index.php?title=Architecture_ZFS_for_...
>Поэтому выдавать ваши измышления о использовании FUSE за действительность - не стоит.
>
>Fuse нет, небыло и не будет в люстре - может быть на
>клиенте - и то для моих эксперементов.Интересно, кому мне стоит верить - пресс-релизу Sun, владельца Lustre, или посетителю форума opennet?
Или этой ссылке с сайта lustre: http://wiki.lustre.org/index.php?title=Fuse полагаю клиент уже давно готов.
В догонку, вы наверное читали мой блог, где я давал ссылку на тестирование инженерами sun производительности lustre с fuse и sun raw device. С чего бы это они стали тестировать fuse, если перехода не будет?
>В догонку, вы наверное читали мой блог, где я давал ссылку на
>тестирование инженерами sun производительности lustre с fuse и sun raw device.
>С чего бы это они стали тестировать fuse, если перехода не
>будет?Впрочем, здесь я ошибся, там не fuse, а некое userspace решение с dmu.
Я согласен, что _НЕТ_ 100% утверждения, что lustre будет работать через FUSE.
Но Sun наняла ZFS-FUSE разработчика, Sun переводит Lustre в userspace, есть клиентский FUSE порт на wiki (не знаю насчет его функциональности).Пока _все_ вышеперечисленные решения медленнее родных, так что, несмотря на ваши заверения, что все в порядке, это симптом.
>[оверквотинг удален]
>>>еще куча ядер вышла без поддержки от Lustre.
>>
>>а зачем сервер без поддержки вещей которые нужны люстре? да и по
>>сути не так уж много надо. Опять же - смотрим внимательно
>>последние pach-series для люстры - что видим - 80% патчей -
>>добаляют экспорты из ядра. Так что вам стоит ознакомиться детальнее с
>>тем что говорите.
>
>Не уходите от темы. напомню, что она звучит так: lustr содержит огромную
>кодовую базу, которую не принимают и не будут принимать в ядро.Кодовую базу всей люстры? да - не будут, патчи - прекрастно принимают.
А что еще надо? - лиш бы глюки ядер фиксили и API не ломали.
>Не считая исправления ошибок (и возможно расширения функционала ext*, которое подходит
>для общего использования) Код сервера огромен и выпускался (выпускается до сих
>пор?) только для конкретной версии ядра.пиши еще ;) портирование любого ядерного модуля - требует портирования под определенное ядро (surprise?) - что там говорили о стабильном API? так в чем проблема что портирование делают только когда надо. В этом упрек?
Опять же большая часть портирования идет при портировании клиента - сервер гораздо менее требовательный к ядру.
>
>>Гониш ;) open intent таки в ядре - в принципе вполне устраивает
>>- хотя видимо это на извращенный вкус господ из fs-devel -
>>рулезно делать open из revalidate, а потом подхватывать открытый file.
>>Изврат, но и так жить можно.
>
>Единственное расширение из Lustre. И то про эти интенты говорят жу бог
>знает сколько, не думаю, что этого не было в xfs.не было. lustre их имела с начала 2.4 - тогда и xfs толком не было.
По сути это портированный код из libsysio (Sandia.gov) - там используют intents что бы оптимизировать работу.
Потом патч FMODE_EXEC - тоже люстровый - приняли.
>[оверквотинг удален]
>Процитирую, вы не ослили предпоследний параграф:
>
>Lustre 1.8 is planned for next summer and will introduce user space
>servers for both Linux and Solaris, running with ZFS/DMU. We'll continue
>to support the existing in-kernel servers for Linux with ext3 until
>Lustre 2.0 at the end of the calendar year. In 2.0
>we'll release clustered metadata servers, enabling the same kind of scalability
>for metadata that we have for storage servers today. And, although
>it will also mark the end of in-kernel servers and ext3,
>Linux will remain strategic to the future of Lustre.и? clustred metadata - оно вполне живое - но меняется on disk format, поэтому его не будет в основной ветке. А так вполне есть и живое - даже прошло верификацию в 3х дневном stress testing.
Противоречий никаких.
2.0 в качестве backend будет поддерживать ldiskfs/zfs, дальше планируют оставить zfs - НО
не раньше чем все проблемы zfs будут решены.
>
>>Вы не компетентны в люстре - и собственно по этому ссылку на
>>ваш блог с размышлениями о люстре - вычеркнули из opennet.
>
>Понятия не имею, что было или не было на opennet, тем не
>менее из моих знаний о старой (еще 1.5) lustre похоже ничего
>не поменялось... Хотя конечно процесс идет.
>Много чего поменялось - только вот 1.5 (1.6) это далеко не все, и тем более не HEAD.
>>посоветую читать что-то большее чем about sun и додумывать того чего там
>>нету.
>>к примеру ARCH wiki - http://arch.lustre.org/index.php?title=Architecture_ZFS_for_...
>>Поэтому выдавать ваши измышления о использовании FUSE за действительность - не стоит.
>>
>>Fuse нет, небыло и не будет в люстре - может быть на
>>клиенте - и то для моих эксперементов.
>
>Интересно, кому мне стоит верить - пресс-релизу Sun, владельца Lustre, или посетителю >форума opennet?даже если этот посетель сотрудник sun и член Lustre team ? ;) не arch team - но тем не менее.
>
>Или этой ссылке с сайта lustre: http://wiki.lustre.org/index.php?title=Fuse полагаю клиент уже давно готов.
>щаааас. только под линукс и только при специфической сборке.
>
>В догонку, вы наверное читали мой блог, где я давал ссылку на
>тестирование инженерами sun производительности lustre с fuse и sun raw device.
>С чего бы это они стали тестировать fuse, если перехода не
>будет?не читал - и не видел среди наших документов этого. значит - это что-то не относящееся к люстре.
user space server - не будут иметь ничего общего с fuse, это я могу 1000% сказать.
>>Не считая исправления ошибок (и возможно расширения функционала ext*, которое подходит
>>для общего использования) Код сервера огромен и выпускался (выпускается до сих
>>пор?) только для конкретной версии ядра.
>
>пиши еще ;) портирование любого ядерного модуля - требует портирования под определенное
>ядро (surprise?) - что там говорили о стабильном API? так в
>чем проблема что портирование делают только когда надо. В этом упрек?Новая версия Lustre выходит для каждой версии ядра? Для 1.5 это было далеко не так.
>не было. lustre их имела с начала 2.4 - тогда и xfs
>толком не было.
>По сути это портированный код из libsysio (Sandia.gov) - там используют intents
>что бы оптимизировать работу.
>Потом патч FMODE_EXEC - тоже люстровый - приняли.Возможно так и есть для интентов, но странно, что в xfs не было open for read подсказок.
>[оверквотинг удален]
>>Linux will remain strategic to the future of Lustre.
>
>и? clustred metadata - оно вполне живое - но меняется on disk
>format, поэтому его не будет в основной ветке. А так вполне
>есть и живое - даже прошло верификацию в 3х дневном stress
>testing.
>Противоречий никаких.
>2.0 в качестве backend будет поддерживать ldiskfs/zfs, дальше планируют оставить zfs -
>НО
>не раньше чем все проблемы zfs будут решены.Главная сторока: ... it will also mark the end of in-kernel servers and ext3 ...
>>Интересно, кому мне стоит верить - пресс-релизу Sun, владельца Lustre, или посетителю >форума opennet?
>
>даже если этот посетель сотрудник sun и член Lustre team ? ;)
>не arch team - но тем не менее.Вы-то можете отказаться от слов т.к. чего-то не знали, а sun - уже нет :)
>>Или этой ссылке с сайта lustre: http://wiki.lustre.org/index.php?title=Fuse полагаю клиент уже давно готов.
>>
>щаааас. только под линукс и только при специфической сборке.Ну никто и не говорит, что это релиз. Но тенденция-то есть...
>>>Не считая исправления ошибок (и возможно расширения функционала ext*, которое подходит
>>>для общего использования) Код сервера огромен и выпускался (выпускается до сих
>>>пор?) только для конкретной версии ядра.
>>
>>пиши еще ;) портирование любого ядерного модуля - требует портирования под определенное
>>ядро (surprise?) - что там говорили о стабильном API? так в
>>чем проблема что портирование делают только когда надо. В этом упрек?
>
>Новая версия Lustre выходит для каждой версии ядра? Для 1.5 это было
>далеко не так.Клиент выходит для каждой. Задержки только когда у меня руки заняты другими задачами.
Патчи для .23/.24 есть в багзиле - надо только поискать.
Для .25 - будут как только это вольют в ядро, уж больно сильно в 2.6.24 сломали sysctl.
а для меня это не является приоритетной задачей.
>[оверквотинг удален]
>>format, поэтому его не будет в основной ветке. А так вполне
>>есть и живое - даже прошло верификацию в 3х дневном stress
>>testing.
>>Противоречий никаких.
>>2.0 в качестве backend будет поддерживать ldiskfs/zfs, дальше планируют оставить zfs -
>>НО
>>не раньше чем все проблемы zfs будут решены.
>
>Главная сторока: ... it will also mark the end of in-kernel servers
>and ext3 ...Ближайшее время от этого не планируют отказаться ;)
а в анонсах... не раз менялось - если декларируемое не давало нужной эфективности.
>
>>>Интересно, кому мне стоит верить - пресс-релизу Sun, владельца Lustre, или посетителю >форума opennet?
>>
>>даже если этот посетель сотрудник sun и член Lustre team ? ;)
>>не arch team - но тем не менее.
>
>Вы-то можете отказаться от слов т.к. чего-то не знали, а sun -
>уже нет :)Сан может сказать - "ну не дает оно нужной производительности - будем поддерживать in-kernel". Хотя да - для solaris не планируется in-kernel.
Но мы вроде говорим о Linux ?
>
>>>Или этой ссылке с сайта lustre: http://wiki.lustre.org/index.php?title=Fuse полагаю клиент уже давно готов.
>>>
>>щаааас. только под линукс и только при специфической сборке.
>
>Ну никто и не говорит, что это релиз. Но тенденция-то есть...тенденция? вам не смешно? человек со стороны сделал для своего мака - это запихнули в wiki и оооочень давно не обновляли :)
Я с друзьями сделал порт этого безобразия на FreeBSD, но это не значит что это официально поддерживаемое направление.
>>Вы-то можете отказаться от слов т.к. чего-то не знали, а sun -
>>уже нет :)
>
>Сан может сказать - "ну не дает оно нужной производительности - будем
>поддерживать in-kernel". Хотя да - для solaris не планируется in-kernel.
>Но мы вроде говорим о Linux ?В том-то и дело, что sun хочет, чтобы была одна и та же кодовая база. И будет она поверх udmu, в solaris нативно, а в linux через zfs-fuse. Почему нет? Раз уж sun утверждает (хорошо, пока утверждает), что поддержки ядерной части в 2.0 не будет.
>>Ну никто и не говорит, что это релиз. Но тенденция-то есть...
>
>тенденция? вам не смешно? человек со стороны сделал для своего мака -
>это запихнули в wiki и оооочень давно не обновляли :)
>Я с друзьями сделал порт этого безобразия на FreeBSD, но это не
>значит что это официально поддерживаемое направление.заодно добавили большой roadmap.
>
>>>Вы-то можете отказаться от слов т.к. чего-то не знали, а sun -
>>>уже нет :)
>>
>>Сан может сказать - "ну не дает оно нужной производительности - будем
>>поддерживать in-kernel". Хотя да - для solaris не планируется in-kernel.
>>Но мы вроде говорим о Linux ?
>
>В том-то и дело, что sun хочет, чтобы была одна и та
>же кодовая база.у кого одна база? у zfs и lustre? найдите в себе силы прочитать структуру zfs.
люстре нужен сторадж с поддержкой транзакций (на oss/ost) - это все предоставляет libzpool - ака DMU.
дальше поверх этого строится файловая система (директории/файлы/etc) - так что страдж с транзакциями - общий, а до самой zfs (как таковой) - люстре дела нету.> И будет она поверх udmu, в solaris нативно,
>а в linux через zfs-fuse. Почему нет? Раз уж sun утверждает
>(хорошо, пока утверждает), что поддержки ядерной части в 2.0 не будет.Потому что для lustre (особенно на oss/ost) не нужна fs вобще, от нее только геморой.
а для zfs нужна.>
>>>Ну никто и не говорит, что это релиз. Но тенденция-то есть...
>>
>>тенденция? вам не смешно? человек со стороны сделал для своего мака -
>>это запихнули в wiki и оооочень давно не обновляли :)
>>Я с друзьями сделал порт этого безобразия на FreeBSD, но это не
>>значит что это официально поддерживаемое направление.
>
>заодно добавили большой roadmap.и что? roadmap - это общее направление, конкретная раскладка по релизам - это другое.
Многие вещи которые не планировались в 1.6 были там реализованы - и ничего.
Так и наоборот - 1.8 с поддержкой clustered metadata планировалось на лето, перенесли в 2.0 и на поздний срок.
>>В том-то и дело, что sun хочет, чтобы была одна и та
>>же кодовая база.
>
>у кого одна база? у zfs и lustre? найдите в себе силы
>прочитать структуру zfs.
>люстре нужен сторадж с поддержкой транзакций (на oss/ost) - это все предоставляет
>libzpool - ака DMU.
>дальше поверх этого строится файловая система (директории/файлы/etc) - так что страдж с
>транзакциями - общий, а до самой zfs (как таковой) - люстре
>дела нету.У вас какая-то паранойя, вы везде пытаетесь подставить глупость, которой там нет.
Одна кодовая база lustre для запуска на любой поддерживаемой платформе. Может быть с небольшими хаками, но без полного портирования на solaris vfs. например если все в userspace.>> И будет она поверх udmu, в solaris нативно,
>>а в linux через zfs-fuse. Почему нет? Раз уж sun утверждает
>>(хорошо, пока утверждает), что поддержки ядерной части в 2.0 не будет.
>
>Потому что для lustre (особенно на oss/ost) не нужна fs вобще, от
>нее только геморой.
>а для zfs нужна.Поэтому sun придется либо поддерживать две кодобых базы (userspace для solaris, kernel/ext* для linux), либо удалить ядерную часть из linux...
>и что? roadmap - это общее направление, конкретная раскладка по релизам -
>это другое.
>Многие вещи которые не планировались в 1.6 были там реализованы - и
>ничего.
>Так и наоборот - 1.8 с поддержкой clustered metadata планировалось на лето,
>перенесли в 2.0 и на поздний срок.Мы как раз и говорим о том, что может быть с lustre. В планах sun - грохнуть kernel server, в ваших планах этого нет.
>
>Одна кодовая база lustre для запуска на любой поддерживаемой платформе. Может быть
>с небольшими хаками, но без полного портирования на solaris vfs. например
>если все в userspace.кого? сервер? серверу VFS даром не нужен, еще раз говорю - он там мешает (особенно на oss). Нужен сторад с транзакциями.
А клиент под Solaris vfs - будет.
>>
>>Потому что для lustre (особенно на oss/ost) не нужна fs вобще, от
>>нее только геморой.
>>а для zfs нужна.
>
>Поэтому sun придется либо поддерживать две кодобых базы (userspace для solaris, kernel/ext*
>для linux), либо удалить ядерную часть из linux...код очень портабельный, а от стораджа с транзакциями - много не надо.
>>- Поддержание локального кэша для данных и мета-данных, согласованного для всех
>>узлов использующих ФС;
>
>lustreКстати, а там разве не write-through кэш?
Класс. А лицензия какая? Под FreeBSD теоретически будет?
>Класс. А лицензия какая? Под FreeBSD теоретически будет?Для Linux однозначно GPLv2. Под FreeBSD только если система будет популярна в Linux, и люди захотят совместимость.
>Для Linux однозначно GPLv2. Под FreeBSD только если система будет популярна в Linux, и люди захотят совместимость.Учитавая что линь все больше становится десктопом ... под BSD было бы очень кстати ...
А есть git-репозиторий?
>А есть git-репозиторий?Локальный :)
Нужен экспорт?
>>А есть git-репозиторий?
>Локальный :)
>Нужен экспорт?Было бы очень хорошо, если бы его можно было бы git clone ;)
И чтобы на видном месте была ссылка.
>>>А есть git-репозиторий?
>>Локальный :)
>>Нужен экспорт?
>
>Было бы очень хорошо, если бы его можно было бы git clone
>;)
>И чтобы на видном месте была ссылка.Со следующим релизом будет экспортировнное дерево.
статью не читал, но название понравилось :)