Zach Brown ведет работу (http://tservice.net.ru/~s0mbre/blog/devel/fs/2007_11_24.html) над созданием сетевой Файловой системы CRFS (Coherent Remote File System). CRFS похожа на NFS, но с возможностью кэширвования данных на клиентской стороне.
Все файловые операции производится на локально прокэшированных данных, с дальнейшей фоновой синхронизацией кэша. Если данных в кэше не оказалось, они загружаются с сервера.
Так как проект CRFS развивается в недрах компании Oracle и дата открытия исходных текстов неизвестна, Евгений Поляков решил (http://tservice.net.ru/~s0mbre/blog/devel/fs/2007_11_24.html) создать ФС работающую по тем же принципам, но развивающуюся как открытый проект.URL: http://tservice.net.ru/~s0mbre/blog/devel/fs/2007_11_24.html
Новость: http://www.opennet.me/opennews/art.shtml?num=12923
Иммм... енто типа замена NFS+CacheFS чтоли или ента FS будет чем-то принципиально отличаться от связки NFS+CacheFS??:-\
Не будет отличаться совсем... Опять изобретаем велосипед.
>Не будет отличаться совсем... Опять изобретаем велосипед.Больше велосипедов , качественнее выбор.
еще один AFS?
Те, кто говорят, что это ничем не отличается от NFS, никогда с NFS по-настоящему не работали. Этот long-dead протокол давно пора переписать.
> Те, кто говорят, что это ничем не отличается от NFS, никогда с NFS по-настоящему не работали. Этот long-dead протокол давно пора переписать.Вы прокакую его версию говорите, чем NFSv4 плох??:)
>Вы прокакую его версию говорите, чем NFSv4 плох??:)nfsv4 (а конкретно pnfs) плох хотя бы тем, что позволяет встраивать в протокол собственные расширения, что приводит к тому, что две реализации _открытого_ протокола не могут друг с другом разговаривать, т.к. не реализованы те или иные расширения. Получается очень серьезная привязка к вендору...
А вспоминая тройку - никогда не висели клиенты после отвала сервера пусть даже на несколько секунд?
Висели в тройке, ну я бы не назвал это критической проблемой, так как при падение сервера, задержки будут у любого протокола, а вот про NFSv4, так извените, OpenSource рулит, делаю что хочу и как хочу, такая проблема может быть у любого открытого протокола, кто помешает вендору взять и добавить что-то в этом протокол, что делает Oracle, хотя он пока не известно будет ли вообще открытым, но если будет, то никто не помешает вендору добавить что-то от себя, так что это тоже не минус и не проблема...:(
>Висели в тройке, ну я бы не назвал это критической проблемой, так
>как при падение сервера, задержки будут у любого протокола, а вот
>про NFSv4, так извените, OpenSource рулит, делаю что хочу и как
>хочу, такая проблема может быть у любого открытого протокола, кто помешает
>вендору взять и добавить что-то в этом протокол, что делает Oracle,
>хотя он пока не известно будет ли вообще открытым, но если
>будет, то никто не помешает вендору добавить что-то от себя, так
>что это тоже не минус и не проблема...:(В том-то и дело, что в открытом протоколе нет возможности добавить закрытые расширения.
В тройке при отвале сервера клиенты часто зависают навечно, даже если север поднялся вновь.
Масштабируемость NFS весьма и весьма плоха (попробуйте параллельно создавать и удалять много файлов в директории). NFS'ный протокол сложен и огромен (и полностью не реализован, btw, в Linux).Cachefs это несколько иное - 1. требует отдельного устройства для кэширования (локальный диск или ramdisk), 2. не поддерживает механизмы когерентности кэшей, 3. никак не привязан к клиентской VFS.
Так что полностью поддерживаю автора в его начинании - NFS must die :)
И вообще PNFS - это NFSv4.1 который пока ещё в Development статусе, поэтому говорить о том, что в нём что-то не так, его ещё не приняли, как стандарт в IETF, поэтому вендоры и играються, используйте NFSv4 и будет Вам счастье...;)
> В том-то и дело, что в открытом протоколе нет возможности добавить закрытые расширения.Хм... запутался, Вы разные Анонимусы?? Тогда, как же в открытом NFSv4.1 у прошлого Анонимуса появляются какие-то расширения и кто сказал, что они закрыты??:-\
> В тройке при отвале сервера клиенты часто зависают навечно, даже если север поднялся вновь.
Не наблюдал, по крайней мере на Linux(CentOS, ASP Linux), FreeBSD начиная с 5.4 и Solaris 10, опции монтирования указывал правда с soft(Linux, FreeBSD), чтобы не вешать клиента бесконечным ожиданием пока восстановится сервер.
> Масштабируем ость NFS весьма и весьма плоха (попробуйте параллельно создавать и удалять много файлов в директории). NFS'ный протокол сложен и огромен (и полностью не реализован, btw, в Linux).Опять же NFSv4.1 и есть этот не хватающий кусочек, почитайте про него - это Parallel NFS - http://www.iaps.com/nfsv4.1-new-features.html
> Cachefs это несколько иное - 1. требует отдельного устройства для кэширования (локальный диск или ramdisk), 2. не поддерживает механизмы когерентности кэшей, 3. никак не привязан к клиентской VFS.
Почему отдельного, достаточно хранить кеш на том же носители, куда монтируется NFS каталог, не вижу тут проблем, что касается 2 и 3, тут конечно нечего не скажешь.
> Так что полностью поддерживаю автора в его начинании - NFS must die :)
Это Ваше право конечно, главное чтобы только новая FS от Oracle была открытой и хоть кем-то использовалась, а то примеров велосипедов и правда много, как говорили предыдущие ораторы.
>> В том-то и дело, что в открытом протоколе нет возможности добавить закрытые расширения.
>
>Хм... запутался, Вы разные Анонимусы?? Тогда, как же в открытом NFSv4.1 у
>прошлого Анонимуса появляются какие-то расширения и кто сказал, что они закрыты??:-\Почитайте на досуге draft-17.
Цитата: A layout describes the mapping of a file's data to the storage devices that hold the data. A layout is said to belong to a specific layout type (data type layouttype4, see Section 3.2.15 (layouttype4)). The layout type allows for variants to handle different storage protocols, such as those associated with block/volume [30] (Black, D., “pNFS Block/Volume Layout,” July 2005.), object [29] (Zelenka, J., Welch, B., and B. Halevy, “Object-based pNFS Operations,” July 2005.), and file (Section 13 (PNFS: NFSv4.1 File Layout Type)) layout types. A metadata server, along with its control protocol, MUST support at least one layout type. A private sub-range of the layout type name space is also defined. Values from the private layout type range MAY be used for internal testing or experimentation.
>> Масштабируем ость NFS весьма и весьма плоха (попробуйте параллельно создавать и удалять много файлов в директории). NFS'ный протокол сложен и огромен (и полностью не реализован, btw, в Linux).
>
>Опять же NFSv4.1 и есть этот не хватающий кусочек, почитайте про него
>- это Parallel NFS - http://www.iaps.com/nfsv4.1-new-features.htmlДа-да, хваленый pnfs... Overbloated протокол с привязкой к вендору, да и никем еще не реализованный.
>Это Ваше право конечно, главное чтобы только новая FS от Oracle была
>открытой и хоть кем-то использовалась, а то примеров велосипедов и правда
>много, как говорили предыдущие ораторы.Я вообще поддерживал открытую разработку, но по сути все равно, конкуренция - сила!
Умолчальный nfsv4 (без kerberos) не поддерживает контрольные суммы для данных и метаданных. Да, его потом расширили и наверное kerberos поддерживается по умолчанию во всех дистрибутивах, но это ли не признак кривого протокола?
"Все файловые операции производится на локально прокэшированных данных, с дальнейшей фоновой синхронизацией кэша."Мазохисты. Опять будут городить сложное и глючное. Каждый раз одно и тоже: как только понадобяться блокировки так вся эта кешированная трихому-ия на стороне килента станет занозой в заднице. И ведь уже полно примеров реализаций и последующих отказов от этого. И теория неплохо давно описана. А нет надо самим на это наступить. Мазохисты.
>Мазохисты. Опять будут городить сложное и глючное. Каждый раз одно и тоже:
>как только понадобяться блокировки так вся эта кешированная трихому-ия на стороне
>килента станет занозой в заднице. И ведь уже полно примеров реализаций
>и последующих отказов от этого. И теория неплохо давно описана. А
>нет надо самим на это наступить. Мазохисты.По ссылкам не ходили? Там предполагается механизм когерентности кэшей.
И что за теория быстрой работы без кэшей, просвятите общественность?
>>Мазохисты. Опять будут городить сложное и глючное. Каждый раз одно и тоже:
>>как только понадобяться блокировки так вся эта кешированная трихому-ия на стороне
>>килента станет занозой в заднице. И ведь уже полно примеров реализаций
>>и последующих отказов от этого. И теория неплохо давно описана. А
>>нет надо самим на это наступить. Мазохисты.
>
>По ссылкам не ходили? Там предполагается механизм когерентности кэшей.
>И что за теория быстрой работы без кэшей, просвятите общественность?Когерентность кэшей файловых систем прниципиально ничем не отличается от того же для кэшей оперативной памяти, а это уже давно обсосано и все грабли известны. Плюс к этому обсосаны алгоритмы обеспечения согласованности распределённых файловых систем. Это про теорию.
Блокировать и кэшировать надо на уровне прикладного ПО ибо только оно знает логическую структуру данных. Sun уже пыталась легко и непринуждённо присклеить к NFS CacheFS на стороне клиента и огребла проблемы при открытии файлов на запись. А Novell на грабли с кэшированием файлов на стороне клиента наступила ешё лет сем-восемь назад и, естественно, попросила не пользоваться. Кто следующий ?
>Когерентность кэшей файловых систем прниципиально ничем не отличается от того же для
>кэшей оперативной памяти, а это уже давно обсосано и все грабли
>известны. Плюс к этому обсосаны алгоритмы обеспечения согласованности распределённых файловых систем.
>Это про теорию.Это всего лишь слова. На самом деле немного отличается - global physical address space намного сложнее представить на нескольких машинах, поэтому проще использовать message passing алгоритмы, которые медленнее. Но это тоже только слова.
>Блокировать и кэшировать надо на уровне прикладного ПО ибо только оно знает
>логическую структуру данных. Sun уже пыталась легко и непринуждённо присклеить к
>NFS CacheFS на стороне клиента и огребла проблемы при открытии файлов
>на запись. А Novell на грабли с кэшированием файлов на стороне
>клиента наступила ешё лет сем-восемь назад и, естественно, попросила не пользоваться.
>Кто следующий ?А gpfs почему-то не наступила с параллельным доступом. Может стоит реализовывать без ошибок в дизайне?
На самом деле проект, если автор его доведет до работоспособного состояния, то это будет отличной заменой NFS на подавляющем большинстве задач.
>Это всего лишь слова. На самом деле немного отличается - global physical
>address space намного сложнее представить на нескольких машинах, поэтому прощеТам global physical address space, здесь Global File System Space. Не вижу принципиальной разницы.
>А gpfs почему-то не наступила с параллельным доступом. Может стоит реализовывать без
>ошибок в дизайне?
>На самом деле проект, если автор его доведет до работоспособного состояния, то
>это будет отличной заменой NFS на подавляющем большинстве задач.Ну так потому и ошибки так как сложные алгоритмы и протоколы. Распределённая обработка перешла лет 10 как на уровень либо транзакций БД либо на потоки сообщений. Кому реально сейчас нужно открывать на запись разделяемые файлы на нескольких машинах ? Если говорить о группе файлов, состовляющих одно логическое целое, то тем более такой группой нужно управлять централизовано в одной точке чтобы гарантировать целостность информации. Обмен данными в виде файлов отмирает так как не учитывает природу и логическую структуру хрнящейся в ней информации. Поэтому никто до сих NFS массово на что-нибудь не меняют. Зачем менять шило на мыло ? Подождать лет пять - оно засохнет и само отвалиться.
>Там global physical address space, здесь Global File System Space. Не вижу
>принципиальной разницы.Память - один массив байт, файлы - на каждый файл разный массив.
>Ну так потому и ошибки так как сложные алгоритмы и протоколы. Распределённая
>обработка перешла лет 10 как на уровень либо транзакций БД либо
>на потоки сообщений. Кому реально сейчас нужно открывать на запись разделяемыеНикуда она не ушли - mpi как был, так и остался.
>файлы на нескольких машинах ? Если говорить о группе файлов, состовляющих
>одно логическое целое, то тем более такой группой нужно управлять централизовано
>в одной точке чтобы гарантировать целостность информации. Обмен данными в виде
>файлов отмирает так как не учитывает природу и логическую структуру хрнящейся
>в ней информации. Поэтому никто до сих NFS массово на что-нибудь
>не меняют. Зачем менять шило на мыло ? Подождать лет пять
>- оно засохнет и само отвалиться.Наличие одной такой точки сводит на нет масштабируемость - с 10 клиентами работает, а с сотней уже нет. Запись в один файл на нескольких машинах _очень_ полезна для научных задач - параллельная запись и чтение сотнями клиентов.
>>Там global physical address space, здесь Global File System Space. Не вижу
>>принципиальной разницы.
>
>Память - один массив байт, файлы - на каждый файл разный массив.Разделяемый файл это тоже массив байт. На этом пожалуй и закончу.
>Разделяемый файл это тоже массив байт. На этом пожалуй и закончу.Серьезное утверждение! :)) Также необходимо отметить, что 2+2=4.
Файлов много, они все разные, плюс операции с метаданными.
Кстати, для справки: mpi алгоритмы проще для реализации когерентности кэшей, поэтому не существует (по крайней мере широко известных) реализаций глобального адресного пространства для сетевых файловых систем (хотя можно назвать "Munin: Distributed Shared Memory Using Multi-Protocol Release Consistency", да и там message passing все время).
По разговорам с автором, предполагается для начала простейший механизм на основе сообщений.
Я тут подумал на досуге, интересно, а как вообще реализовать распределенный кэш без сообщений? В любом случае будут уведомления о смене состояния страницы/ячейки. В SMP это в целом тоже самое, только называется по-другому - cache line invalidate и т.п. а по сути сообщения.