| |
| 2.12, User294 (ok), 00:25, 08/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>красота.
DHT вообще красивая идея само по себе.Ну и системы на их основе разумеется получаются симпатчными в большинстве случаев.
| | |
|
| 1.2, Аноним (-), 14:01, 07/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Эх, не очень селен в английском. Но судя по описанию вещь весьма интересная.
| | |
| 1.4, Аноним (3), 14:27, 07/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ничивоудивительново Parallel Optimized Host Message Exchange Layered File System
| | |
| |
| 2.5, root (??), 15:35, 07/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>ничивоудивительново Parallel Optimized Host Message Exchange Layered File System
и правда ничего в этом нет. к примеру есть такая вещь - зманда - Zmanda is the world’s leading provider of open source backup and recovery software. при утвеждении проекта с таким софтом многие будут приятно удивлены
| | |
| |
| 3.6, anonymous (??), 18:33, 07/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>ничивоудивительново Parallel Optimized Host Message Exchange Layered File System
>
>и правда ничего в этом нет. к примеру есть такая вещь -
>зманда - Zmanda is the world’s leading provider of open source
>backup and recovery software. при утвеждении проекта с таким софтом многие
>будут приятно удивлены
А ещё есть ebXML (http://www.ebxml.org/), что очень весело звучит в устной речи.
| | |
| |
| 4.7, Artzab (?), 18:45, 07/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>>ничивоудивительново Parallel Optimized Host Message Exchange Layered File System
>>
>>и правда ничего в этом нет. к примеру есть такая вещь -
>>зманда - Zmanda is the world’s leading provider of open source
>>backup and recovery software. при утвеждении проекта с таким софтом многие
>>будут приятно удивлены
>
>А ещё есть ebXML (http://www.ebxml.org/), что очень весело звучит в устной речи.
>
Вдогонку XEP и HAXEP (http://services.renderx.com/lists/xep-support/0970.html)
| | |
|
|
|
| 1.8, Аноним (3), 21:38, 07/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Какие-то у них имена файлов (которые совсем не имена файлов) интересные.
Мало того, что ID объектов (файлов или кусков файлов) они берут как хэш от этого имени и про защиту от коллизий нигде не видно, так они еще и не POSIX-совместимые со всяким «/tmp/some_file[null byte]offset or content checksum».
В общем, на первый взгляд выглядит хорошо, но вызывает настороженность.
| | |
| |
| 2.9, Аноним (3), 21:54, 07/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Какие-то у них имена файлов (которые совсем не имена файлов) интересные.
>
>Мало того, что ID объектов (файлов или кусков файлов) они берут как
>хэш от этого имени и про защиту от коллизий нигде не
>видно, так они еще и не POSIX-совместимые со всяким «/tmp/some_file[null byte]offset
>or content checksum».
А там вообще нет понятий файл, директория и т.п. И к POSIX это не имеет никакого отношения.
Это похоже скорее скорее на object storage, в описании часто это словосочетание употребляется.
Соответственно, собственный API, а POHMELFS - это как раз POSIX "клиент" для этого хранилища.
Коллизии разрешаются использованием двойного/тройного и т.д. хеширования, или правильнее наверное преобразования.
ID объекта может быть любая последовательность байт определенной длины, наверное поэтому функция преобразования была переименована из hash в transform :)
А идентификатором в примере в библиотеке служит либо хеш от имени, либо хеш от содержимого пакета. Функцию генерации ID можно подставить любую свою.
Выглядит очень интересно, будем смотреть.
| | |
| |
| 3.10, Аноним (3), 22:09, 07/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А там вообще нет понятий файл, директория и т.п. И к POSIX
>это не имеет никакого отношения.
>Это похоже скорее скорее на object storage, в описании часто это словосочетание
>употребляется.
>Соответственно, собственный API, а POHMELFS - это как раз POSIX "клиент" для
>этого хранилища.
О как:
I will think on the idea of providing not only file based backends for the nodes, but also stackable solutions like with transformation functions, when server provides a callback to store data, and will place it either as a file in some dir, or database update or anything else.
| | |
|
|
| 1.13, Rush (??), 01:32, 08/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Пока к эпилептику не прикрутят фронтенд в виде файловой системы массового применения не будет. Не потому, что коряво - идея с последовательностью клиентских хэш-функций для группировки трафика по датацентрам и географическим регионам очень хороша. А потому, что пока что этой библией может воспользоваться только программист, админу тут ловить нечего. К тому же не понятно, что происходит при попытке получения части файла, уже содержащейся в локальном кеше. Скорее всего (судя по краткому примеру) - получение заново, а это не то, чего хотелось бы.
| | |
| |
| 2.14, Аноним (3), 01:52, 08/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Пока к эпилептику не прикрутят фронтенд в виде файловой системы массового применения
>не будет. Не потому, что коряво - идея с последовательностью клиентских
>хэш-функций для группировки трафика по датацентрам и географическим регионам очень хороша.
>А потому, что пока что этой библией может воспользоваться только программист,
>админу тут ловить нечего. К тому же не понятно, что происходит
>при попытке получения части файла, уже содержащейся в локальном кеше. Скорее
>всего (судя по краткому примеру) - получение заново, а это не
>то, чего хотелось бы.
Зачем запрашивать ту часть, которая уже есть в кэше?
| | |
| |
| 3.15, Rush (??), 14:52, 08/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Зачем запрашивать ту часть, которая уже есть в кэше?
Rush>>А потому, что пока что этой библией может воспользоваться только программист,
Rush>>админу тут ловить нечего.
Собственно я уже ответил на этот вопрос. Но повторюсь - библия работает с объектами. Упрощённый интерфейс позволяет работать с файлами. Механизма кеширования нет как такового, эта работа ложится на программиста фронтенда. То бишь для создания кеша программисту фронтенда нужно реализовать как минимум карты кэша и гранулировать файлы. А так же предусмотреть интерлоки и прочая прочая связанная с многопользовательской составляющей любой ФС. Проще говоря - мне бы пригодился именно такой фронтенд, а подобный бэкенд я бы написал и сам, причём так, как мне надо (мне не подходит идеология облаков, у меня взвешенный граф).
| | |
| |
| 4.16, Аноним (3), 16:50, 08/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Собственно я уже ответил на этот вопрос. Но повторюсь - библия работает
>с объектами. Упрощённый интерфейс позволяет работать с файлами. Механизма кеширования нет
>как такового, эта работа ложится на программиста фронтенда. То бишь для
>создания кеша программисту фронтенда нужно реализовать как минимум карты кэша и
>гранулировать файлы. А так же предусмотреть интерлоки и прочая прочая связанная
>с многопользовательской составляющей любой ФС. Проще говоря - мне бы пригодился
>именно такой фронтенд, а подобный бэкенд я бы написал и сам,
>причём так, как мне надо (мне не подходит идеология облаков, у
>меня взвешенный граф).
Для VFS кэша есть POHMELFS - используйте ее для своего бэкенда, протокол открыт.
Хотя у автора написано, что портирование POHMELFS сервера на эту библиотеку пока в TODO листе.
Для какого-то собственного кэша - можно считывать куски файлов. В том виде, в котором представлена библиотека с простейшим примером использования, да, пожалуй админам не разгуляться, хотя для какого-нибудь бэкапа на кучу машин или хранения редко-используемых данных - самое то.
| | |
| |
| 5.19, Анонимус (?), 08:32, 11/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Для какого-то собственного кэша - можно считывать куски файлов. В том виде,
>в котором представлена библиотека с простейшим примером использования, да, пожалуй админам
>не разгуляться, хотя для какого-нибудь бэкапа на кучу машин или хранения
>редко-используемых данных - самое то.
сорри, скорее для редко "изменяемых/обновляемых" данных
| | |
|
|
|
|
|
