| 1.1, ZANSWER (??), 08:08, 26/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Иммм... енто типа замена NFS+CacheFS чтоли или ента FS будет чем-то принципиально отличаться от связки NFS+CacheFS??:-\
| | |
| |
| 2.4, GR (??), 12:00, 26/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Не будет отличаться совсем... Опять изобретаем велосипед.
Больше велосипедов , качественнее выбор.
| | |
|
| 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. Не вижу
>>принципиальной разницы.
>
>Память - один массив байт, файлы - на каждый файл разный массив.
Разделяемый файл это тоже массив байт. На этом пожалуй и закончу.
| | |
|
|
|
|
|
|
|
