The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Сетевая файловая система с кэшированием данных

25.11.2007 22:56

Zach Brown ведет работу над созданием сетевой Файловой системы CRFS (Coherent Remote File System). CRFS похожа на NFS, но с возможностью кэширвования данных на клиентской стороне.

Все файловые операции производится на локально прокэшированных данных, с дальнейшей фоновой синхронизацией кэша. Если данных в кэше не оказалось, они загружаются с сервера.

Так как проект CRFS развивается в недрах компании Oracle и дата открытия исходных текстов неизвестна, Евгений Поляков решил создать ФС работающую по тем же принципам, но развивающуюся как открытый проект.

  1. Главная ссылка к новости (http://tservice.net.ru/~s0mbre...)
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: nfs, cache
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (21) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, ZANSWER (??), 08:08, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Иммм... енто типа замена NFS+CacheFS чтоли или ента FS будет чем-то принципиально отличаться от связки NFS+CacheFS??:-\
     
  • 1.2, Аноним (-), 09:41, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не будет отличаться совсем... Опять изобретаем велосипед.
     
     
  • 2.4, GR (??), 12:00, 26/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Не будет отличаться совсем... Опять изобретаем велосипед.

    Больше велосипедов , качественнее выбор.


     

  • 1.3, bodun (?), 09:57, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    еще один AFS?

     
  • 1.5, Аноним (-), 12:51, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Те, кто говорят, что это ничем не отличается от NFS, никогда с NFS по-настоящему не работали. Этот long-dead протокол давно пора переписать.
     
  • 1.6, ZANSWER (??), 13:34, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Те, кто говорят, что это ничем не отличается от NFS, никогда с NFS по-настоящему не работали. Этот long-dead протокол давно пора переписать.

    Вы прокакую его версию говорите, чем NFSv4 плох??:)

     
     
  • 2.7, Аноним (-), 14:00, 26/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы прокакую его версию говорите, чем NFSv4 плох??:)

    nfsv4 (а конкретно pnfs) плох хотя бы тем, что позволяет встраивать в протокол собственные расширения, что приводит к тому, что две реализации _открытого_ протокола не могут друг с другом разговаривать, т.к. не реализованы те или иные расширения. Получается очень серьезная привязка к вендору...

    А вспоминая тройку - никогда не висели клиенты после отвала сервера пусть даже на несколько секунд?

     

  • 1.8, ZANSWER (??), 15:09, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Висели в тройке, ну я бы не назвал это критической проблемой, так как при падение сервера, задержки будут у любого протокола, а вот про NFSv4, так извените, OpenSource рулит, делаю что хочу и как хочу, такая проблема может быть у любого открытого протокола, кто помешает вендору взять и добавить что-то в этом протокол, что делает Oracle, хотя он пока не известно будет ли вообще открытым, но если будет, то никто не помешает вендору добавить что-то от себя, так что это тоже не минус и не проблема...:(
     
     
  • 2.10, Аноним (-), 15:31, 26/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Висели в тройке, ну я бы не назвал это критической проблемой, так
    >как при падение сервера, задержки будут у любого протокола, а вот
    >про NFSv4, так извените, OpenSource рулит, делаю что хочу и как
    >хочу, такая проблема может быть у любого открытого протокола, кто помешает
    >вендору взять и добавить что-то в этом протокол, что делает Oracle,
    >хотя он пока не известно будет ли вообще открытым, но если
    >будет, то никто не помешает вендору добавить что-то от себя, так
    >что это тоже не минус и не проблема...:(

    В том-то и дело, что в открытом протоколе нет возможности добавить закрытые расширения.

    В тройке при отвале сервера клиенты часто зависают навечно, даже если север поднялся вновь.
    Масштабируемость NFS весьма и весьма плоха (попробуйте параллельно создавать и удалять много файлов в директории). NFS'ный протокол сложен и огромен (и полностью не реализован, btw, в Linux).

    Cachefs это несколько иное - 1. требует отдельного устройства для кэширования (локальный диск или ramdisk), 2. не поддерживает механизмы когерентности кэшей, 3. никак не привязан к клиентской VFS.

    Так что полностью поддерживаю автора в его начинании - NFS must die :)

     

  • 1.9, ZANSWER (??), 15:19, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И вообще PNFS - это NFSv4.1 который пока ещё в Development статусе, поэтому говорить о том, что в нём что-то не так, его ещё не приняли, как стандарт в IETF, поэтому вендоры и играються, используйте NFSv4 и будет Вам счастье...;)
     
  • 1.11, ZANSWER (??), 17:37, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В том-то и дело, что в открытом протоколе нет возможности добавить закрытые расширения.

    Хм... запутался, Вы разные Анонимусы?? Тогда, как же в открытом 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 была открытой и хоть кем-то использовалась, а то примеров велосипедов и правда много, как говорили предыдущие ораторы.

     
     
  • 2.12, Аноним (-), 08:41, 27/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >> В том-то и дело, что в открытом протоколе нет возможности добавить закрытые расширения.
    >
    >Хм... запутался, Вы разные Анонимусы?? Тогда, как же в открытом 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 была
    >открытой и хоть кем-то использовалась, а то примеров велосипедов и правда
    >много, как говорили предыдущие ораторы.

    Я вообще поддерживал открытую разработку, но по сути все равно, конкуренция - сила!

     
     
  • 3.13, Аноним (-), 08:57, 27/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Умолчальный nfsv4 (без kerberos) не поддерживает контрольные суммы для данных и метаданных. Да, его потом расширили и наверное kerberos поддерживается по умолчанию во всех дистрибутивах, но это ли не признак кривого протокола?
     

  • 1.14, belkin (??), 09:48, 27/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Все файловые операции производится на локально прокэшированных данных, с дальнейшей фоновой синхронизацией кэша."

    Мазохисты. Опять будут городить сложное и глючное. Каждый раз одно и тоже: как только понадобяться блокировки так вся эта кешированная трихому-ия на стороне килента станет занозой в заднице. И ведь уже полно примеров реализаций и последующих отказов от этого. И теория неплохо давно описана. А нет надо самим на это наступить. Мазохисты.

     
     
  • 2.15, Аноним (-), 10:15, 27/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Мазохисты. Опять будут городить сложное и глючное. Каждый раз одно и тоже:
    >как только понадобяться блокировки так вся эта кешированная трихому-ия на стороне
    >килента станет занозой в заднице. И ведь уже полно примеров реализаций
    >и последующих отказов от этого. И теория неплохо давно описана. А
    >нет надо самим на это наступить. Мазохисты.

    По ссылкам не ходили? Там предполагается механизм когерентности кэшей.
    И что за теория быстрой работы без кэшей, просвятите общественность?

     
     
  • 3.16, belkin (??), 10:18, 28/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>Мазохисты. Опять будут городить сложное и глючное. Каждый раз одно и тоже:
    >>как только понадобяться блокировки так вся эта кешированная трихому-ия на стороне
    >>килента станет занозой в заднице. И ведь уже полно примеров реализаций
    >>и последующих отказов от этого. И теория неплохо давно описана. А
    >>нет надо самим на это наступить. Мазохисты.
    >
    >По ссылкам не ходили? Там предполагается механизм когерентности кэшей.
    >И что за теория быстрой работы без кэшей, просвятите общественность?

    Когерентность кэшей файловых систем прниципиально ничем не отличается от того же для кэшей оперативной памяти, а это уже давно обсосано и все грабли известны. Плюс к этому обсосаны алгоритмы обеспечения согласованности распределённых файловых систем. Это про теорию.

    Блокировать и кэшировать надо на уровне прикладного ПО ибо только оно знает логическую структуру данных. Sun уже пыталась легко и непринуждённо присклеить к NFS CacheFS на стороне клиента и огребла проблемы при открытии файлов на запись. А Novell на грабли с кэшированием файлов на стороне клиента наступила ешё лет сем-восемь назад и, естественно, попросила не пользоваться. Кто следующий ?

     
     
  • 4.17, Аноним (-), 13:07, 28/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Когерентность кэшей файловых систем прниципиально ничем не отличается от того же для
    >кэшей оперативной памяти, а это уже давно обсосано и все грабли
    >известны. Плюс к этому обсосаны алгоритмы обеспечения согласованности распределённых файловых систем.
    >Это про теорию.

    Это всего лишь слова. На самом деле немного отличается - global physical address space намного сложнее представить на нескольких машинах, поэтому проще использовать message passing алгоритмы, которые медленнее. Но это тоже только слова.

    >Блокировать и кэшировать надо на уровне прикладного ПО ибо только оно знает
    >логическую структуру данных. Sun уже пыталась легко и непринуждённо присклеить к
    >NFS CacheFS на стороне клиента и огребла проблемы при открытии файлов
    >на запись. А Novell на грабли с кэшированием файлов на стороне
    >клиента наступила ешё лет сем-восемь назад и, естественно, попросила не пользоваться.
    >Кто следующий ?

    А gpfs почему-то не наступила с параллельным доступом. Может стоит реализовывать без ошибок в дизайне?
    На самом деле проект, если автор его доведет до работоспособного состояния, то это будет отличной заменой NFS на подавляющем большинстве задач.

     
     
  • 5.18, belkin (??), 16:11, 28/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Это всего лишь слова. На самом деле немного отличается - global physical
    >address space намного сложнее представить на нескольких машинах, поэтому проще

    Там global physical address space, здесь Global File System Space. Не вижу принципиальной разницы.

    >А gpfs почему-то не наступила с параллельным доступом. Может стоит реализовывать без
    >ошибок в дизайне?
    >На самом деле проект, если автор его доведет до работоспособного состояния, то
    >это будет отличной заменой NFS на подавляющем большинстве задач.

    Ну так потому и ошибки так как сложные алгоритмы и протоколы. Распределённая обработка перешла лет 10 как на уровень либо транзакций БД либо на потоки сообщений. Кому реально сейчас нужно открывать на запись разделяемые файлы на нескольких машинах ? Если говорить о группе файлов, состовляющих одно логическое целое, то тем более такой группой нужно управлять централизовано в одной точке чтобы гарантировать целостность информации. Обмен данными в виде файлов отмирает так как не учитывает природу и логическую структуру хрнящейся в ней информации. Поэтому никто до сих NFS массово на что-нибудь не меняют. Зачем менять шило на мыло ? Подождать лет пять - оно засохнет и само отвалиться.

     
     
  • 6.19, Аноним (-), 16:51, 28/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Там global physical address space, здесь Global File System Space. Не вижу
    >принципиальной разницы.

    Память - один массив байт, файлы - на каждый файл разный массив.

    >Ну так потому и ошибки так как сложные алгоритмы и протоколы. Распределённая
    >обработка перешла лет 10 как на уровень либо транзакций БД либо
    >на потоки сообщений. Кому реально сейчас нужно открывать на запись разделяемые

    Никуда она не ушли - mpi как был, так и остался.

    >файлы на нескольких машинах ? Если говорить о группе файлов, состовляющих
    >одно логическое целое, то тем более такой группой нужно управлять централизовано
    >в одной точке чтобы гарантировать целостность информации. Обмен данными в виде
    >файлов отмирает так как не учитывает природу и логическую структуру хрнящейся
    >в ней информации. Поэтому никто до сих NFS массово на что-нибудь
    >не меняют. Зачем менять шило на мыло ? Подождать лет пять
    >- оно засохнет и само отвалиться.

    Наличие одной такой точки сводит на нет масштабируемость - с 10 клиентами работает, а с сотней уже нет. Запись в один файл на нескольких машинах _очень_ полезна для научных задач - параллельная запись и чтение сотнями клиентов.

     
     
  • 7.20, belkin (??), 17:07, 28/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>Там global physical address space, здесь Global File System Space. Не вижу
    >>принципиальной разницы.
    >
    >Память - один массив байт, файлы - на каждый файл разный массив.

    Разделяемый файл это тоже массив байт. На этом пожалуй и закончу.

     
     
  • 8.21, Аноним (-), 17:38, 28/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Серьезное утверждение Также необходимо отметить, что 2 2 4 Файлов много, о... текст свёрнут, показать
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру