Выжимка из «универсального формата файла» от TripleGluk

Спасение данных после смерти винта навело ещё на одно достоинства универсального формата. При полном уничтожении системной инфы умные софтины тем не менее восстанавливают файлы с ИЗВЕСТНОЙ СТРУКТУРОЙ. Таковых, как правило весьма ограниченное количество (не говоря уж о том, что в некоторых файлах нет данных об их длинне).

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

>предлагаю задуматься вот о чем. Файлы состоят "из кусочков", после копирования/вставки "кусочка" в новый/правки старого файла, история этого "кусочка" теряется. А если бы история сохранялась, мы могли бы адресовать каждую "уникальную цитату" в тексте, реализовать штуку вроде трансклюзии в гипертексте Xanadu (+читать ещё про их гиперссылки):

Вобще мы сейчас не совсем этот уровень обсуждаем. Речь идет о контейнере, в котором уже могут быть прописаны и история, и связи пр..

>Поэтому, должно быть универсальное обозначение типа, вроде mime-types. Организованное в пространство имён, если потребуется.

mime-types тоже не слишком подробны. Да и с этим я не спорю. Вопрос в том, что этот тип как раз и надо где-то хранить. А вот где - о том и речь.

>Хешем/ключём в таблице лучше считать содержимое файла (без заголовка). Прочитай как устроено "объектное хранилище git",

Почитал. Если честно - практически ничего не понял, как не понял и собственно смысла. Можно кратко повторить тут, в одном месте? Сложно собирать обрывки по кускам цитат, если толком не знаешь, какие куски относятся к делу.

>идея про УФК интересная, но непонятно -- зачем? :)) в смысле, первым пунктом надо рассказать что это даёт нового, не доступного ранее, цели этой идеи. А то прям получается очередное "патентованное средство от всех болезней"

Так вот как раз за этим и надо!:

>Сам файл должен быть "составным", из кусочков+метаданных+ интерфейс обработчика этого типа файлов. При этом может присутствовать в самом контейнере, а может быть ссылкой, откуда скачать "кодек". Скачиваться будет лениво, по требованию, при обращении, если действительно понадобиться. Все промежуточные данные/индексы/запросы можно кешировать если еще раз понадобятся.

>не надо "на глаз определять". Надо дать возможность сохранить дополнительные признаки-метаданные и дать унифицированный интерфейс для добавления метаданных, унифицированный интерфейс для адресации по метаданным (вроде трансляторов в ХУРДе: мы можем пометить файл "тегом" и адресовать по своему пространству имён внутри тегов, вроде .../tags/blabla+yadda+yadda@[size<100k] ).

так одна из и дей и есть универсальный (фс-независимый) способ отметки тэгами. Как частный случай использования.

Не задача, а идея. Явно она сформулирована уже не раз и в этом, и в предидущем топике. Пунктов много, повторять уже не хочу.

>напрашивается сводная таблица по фичам, преимуществам и недостаткам: tar/dmg/iso/cloop/wad/rar/zip/iff/avi/UberUFK :) Чтобы было ясно, чего ради изобретается велосипед :)

Ради чего изобретался велосипед изложено уже не раз как выше в этом, так и в предидущем топике.

>http://en.wikipedia.org/wiki/Cloop

Как вариант тоже сойдёт. Как я уже говорил - смысл не в конкретном формате, а в его универсальности.

> файл-контейнер, содержащий в себе другие файлы, формат которого был бы унифицирован и общепринят.

Поздравляю! Мне кажется, вы только что изобрели tar!

>http://en.wikipedia.org/wiki/Cloop

Да, но он только RO, что годится не всегда.

Занятная штука. Не знал. Но не в тему. Она позволяет виртуально объединять файлы (на сколько я понял) а смысл - объединить их физически.

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

>klik в Линукс сделан по аналогии, можно посмотреть туда.

Ага, понял. Но это относится только к программам, как я понял. Имеет ли смысл делать в таком виде документы? Не нашел инфы, но есть подозрение, что он тоже RO.

> TripleGluk

о, да тут оказывается дискуссия развернулась, а то я накидал ссылок и убежал :))

ещё интересная ссылка в тему:

http://www.sics.se/~joe/ubf/site/home.html

/me убежал перечитывать 2ю страницу

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

И шо вы там такое редактируете в дороге на ноуте, што вам дешевой 4гиговой флешки с Truecrypt-контейнером (для защиты в случае похищения флэшки) для бэкапа не хватает? HD-video поди?

>>Хешем/ключём в таблице лучше считать содержимое файла (без заголовка). Прочитай как устроено "объектное хранилище git",

>Почитал. Если честно - практически ничего не понял, как не понял и собственно смысла. Можно кратко повторить тут, в одном месте? Сложно собирать обрывки по кускам цитат, если толком не знаешь, какие куски относятся к делу.

собственно у меня там было 1.5-2 идеи :) Про уровень хранения для недоСУБД и "аннотированную ФС" адресуемую по метаданным, и про то, что к этой недоСУБД не надо изобретать новый интерфейс доступа, можно обойтись и стандартным open/read/write/close для файлов, про интеграцию этой недоСУБД с обычной ФС.

Вот допустим есть какое-то OLTP приложение с недоСУБД. Объекты, персистентные, прозрачно сохраняются на диск, все дела. Когда можно обойтись ими, когда уже нужен SQL?

Утверждаю, что "высокоуровневый" язык вроде SQL не всегда нужен. Фактически, в 90% случаев он нужен для написания произвольных отчётов по данным объектов хитрыми SELECT'ами с подзапросами (но при этом эти SELECT'ы "ломают" инкапсуляцию объектов). Фактически SQL -- это нормальный язык с компилятором, оптимизатором (планы запроса итп), профилировщиком планов запросов итп.

Можно обойтись недоСУБД в памяти: персистентыми объектами, которые прозрачно сохраняются на диск. Вместо SQL'ных SELECT'ов изобразить какой-то навигационный язык запросов, контролируя инкапсуляцию. Работы вроде базы GOODS К.Книжника показывают, что это может быть сильно быстрее.

Это если подкапываться со стороны СУБД. Со стороны ФС ещё интереснее.

Всё уже изобретено до нас, есть как бы VCS git (а на деле -- toolkit для построения "уровней хранения").

В git "репозиторий" устроен след. образом: есть файлы-объекты-блобы, которые хранятся в "объектной БД" и доступны по адресу-хешу содержимого. Блоб - это префикс из строчки с mime-type файла, строчки с Content-length (длиной), возможно другими заголовками +собсно контент файла. От контента (с префиксом или нет, не важно) считается хеш (sha1) и он используется в качестве ключа, Object ID в этой "ОО БД".

Понятия "имя файла" там нет, все доступны по такому ключу-хешу. Но раз так адресовать неудобно, есть дополнительные "пространства имён" с путями.

Commit в git = "сохранение состояния файлов в директории на момент времени". Он хранится как хеш от ключей-хешей файлов. То есть крипто. подпись конкретного "набора файлов" (без учёта имени файла, то есть если провести аналогию с "составным" файлом, разбитым на кусочки-файлы-блобы, то "переименование" файлов не изменит кусочков-файлов, изменит только метаданные про "имя файла", а содержимое будет то же).

Это что касается уровня хранения в "стандартном git" (сейчас там правда уже 3 года как прикрутили бинарные дельты для оптимизации занимаемого места, ну и локальность кеша чтоб улучшить)

Далее, вот есть файловая система в Plan9. "Всё - это файл" развивается дальше, сетевая фс=файл, удалённый файл и свой прозрачно доступны аналогично"обработчик протокола"=файл-транслятор. Просто http:// или ftp:// монтируется в корень ФС (как это есть в FUSE, sshfs, etc).

Возникает логичные 4 мысли:

1. чем отличается http://snafu.com/blabla.gif и /home/luser/.../blabla.gif, если это физически один и тот же файл, только доступный по разным адресам

2. чем отличаются "протоколы" http://../blabla.gif file:// и например, /proc/someproc/fd/fdID, то есть, что мешает сделать "свой протокол", прозрачный на уровне системы. Да ничего, в HURD и есть "протоколы-трансляторы".

3. чем собственно отличаются уникальные ресурсы-файлы? В Plan9 у каждого окна был свой /dev/window/windowid, и ОС мультиплексировала ресурсы -- распределяла эти windowid чтобы не было конфликтов совместного доступа. То есть со стороны приложения, ему казалось, что у него один-единственный ресурс -- одно окно, а со стороны ОС -- было несколько приложений с корректными разными ссылками в каждом. Типа /proc/app/window -> /dev/window/app_windowid.

4. реализация категорий и тегов над ФС. Ну это в сторону LogicFS копать, вкратце -- отличие от сим- и хардлинков в том, что симлинки ломаются при передвижении файла в другое место (хотя например алиасы в макоси -- аналог симлинков -- не ломались). Вместо этого предлагается сделать "протокол", который логически может адресовать уникальный файл-объект, и поддерживать операции вроде "пометить файл тегом"/"найти по тегу", "добавить тег в категорию", логическое объединение/пересечение множеств категорий и тегов. Категории должны управляться по какому-то автоматическому правилу, логикой над множествами, правилам по "метаданным файла" итп.

Получаем язык запросов над файлами-объектами, которые хранятся в ФС. (кстати, в том топике была ссылка на libferris, XML-ный язык запросов над ФС (или над любым файлом, если монтировать loopback))

штуки вроде ACID-ности тоже можно проэмулировать над таким "БД в ФС".

В общем-то ключевая идея, что внешний интерфейс к такой недоБД можно предоставить обычный файловый, то есть прозрачно отобразить эту недоБД в ФС и наоборот. Например, сделать кеширование вроде squid: внешние объекты-файлы хранятся в единственном экземпляре, а из уровня хранения запросом по "пути с именем файла" выдаются корректные ссылки; сами пути-запросы логично собраны в "интерфейс доступа" с категориями, булевой логикой, языком запроса итп.

> Явно она сформулирована уже не раз и в этом, и в предидущем топике. Пунктов много, повторять уже не хочу.

тогда будет "Сложно собирать обрывки по кускам цитат", чтобы мы не отклонились от главного. Эх, надо в какую-то wiki или pastebin записать, с тезисами, зачем идея понадобилась,чтобы это было обозримо и покрутить в голове, что даёт полезного, что бесполезного, что боян, что велосипед, а что делать НЕ нужно :))

> Но это относится только к программам, как я понял. Имеет ли смысл делать в таком виде документы?

вроде бы comound-файлы в оффтопике и OpenDoc-документы ну сильно на это похожи :)) Проблема в том, что они не являются самодостаточными: если бы это был какой-то самоописываемый "бинарный XML", то можно было бы иметь универсальный reader/writer/проверить корректность документа(схему), и т.п., а так сильно завязаны на реализацию своих reader/writer, без особой универсальности.

Если "схему документа" хранить в нём же, в каком-то стандартном месте, это уже будет более универсально и расширяемо

> Не знал. Но не в тему. Она позволяет виртуально объединять файлы (на сколько я понял) а смысл - объединить их физически.

смысл, именно физически? я так понял, основной смысл идеи -- в расширяемости, и стандартным интерфейсам доступа. физически -- будет слишком завязано на реализацию, а какая нам нафиг разница если /home/luser/.../quake3.pk3/sound/shotgun.wav будет физически в том же файле или доступна по "виртуальному пути" вроде quake://*.pk3/sound/shotgun.wav (браться из конкретного или строиться из других pk3, динамически)?

> Вобще мы сейчас не совсем этот уровень обсуждаем. Речь идет о контейнере, в котором уже могут быть прописаны и история, и связи пр..

это ортогонально, если в качестве "пространства имён" -- ссылок выбрать не такие как в HTML, которые "съезжают" при перемещении материалов или ссылаются на клоны-копии, а такие, как в Xanadu, ссылки по содержимому на "кусочки" файла.

Тогда история перемещений по ссылкам-элементам файла не будет зависить от файла-контейнера, и станет полезной между разными файлами, разными компьютерами. Адресовать каждый отдельный элемент файла, хранить историю из чего что получено.

Эти ссылки должны включать ссылку на файл-контейнер, метаданные, чтобы по ним можно было вытащить недостающие зависимости (кодеки, обработчики протоколов итп)

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

угу, что-то вроде mbox-формата, с заголовками.

Файл := секция1;секция2;..;секцияN

СекцияN := заголовок1 заголовок2 . . . заголовокN контент-блоб

заголовокX := текстовая строка, кончается на \n, вида property list: имя_метаданного: значение\n

набор заголовков "имя_метаданного" произвольный, но есть обязательные

Content-type: text/plain Content-length: 666 <далее идёт контент-блоб> , sizeof(blob)=666

наверное полезно сделать "заголовок" #define:

#define # Content-length: #define ! Content-type: ! text/plain # 666 ...

и "оглавление", например, для файла ввести Секцию0 с данными о остальных секциях.

Сама структура в принципе похожа на XML, только в другом виде. Можно завернуть в XML и наоборот, сделать файл "в конверте" вида <uberml> <indexSection0> <section1> </indexSection0> <section1> <head> <type>text/plain</type> <size>666</size> </head> <body> ... encoded(content) ... </body> </section1> </uberml>

XML как формат хранения -- избыточен, но интересен тем, что он самодостаточен -- для чтения универсального XML достаточно стандартных reader/writer/возможно ещё схемы XML. Для конвертирования из N входных форматов в M выходных надо написать не N*M со своими reader/writer, а N+M вариантов, из "своего" входного в универсальный, из универсального в "свой" выходной.

Выходом XML является построенный DOM; если этот "построенный" DOM+интерфейсы работы с данными хранить в соотв. блобе УФК-файла, можно его "скешировать", получить "компилированный" XML. Лисповые Sexprы тоже хорошо ложаться на идею "кеширования".

Главное, что работа с контентом внутри блобов должна вестись по стандартным интерфейсам и метаданным, на которые есть ссылка (и которые можно засунуть в сам блоб (другой)).

Если метаданные будут стандартизированы, унифицированы, то становится возможным "сливать виртуальные пространства имён" таких двух разных UFK. Так в physfs или в mount -o bind,loop /file1 /mnt && mount -o bind,loop /file2 /mnt.

>Можно кратко повторить тут, в одном месте?

например, как это может выглядеть в "gitfs":

есть путь, по которому /proc/upyachka "монтирует" файлы; путь файла является запросом к нему.

/proc/upyachka/blobs/9cdec69258b03232cc935c463d9356da ## md5 или sha1
/proc/upyachka/blobs/87c752ef880696e6a2dab87fe88dc5f6

метаданные "имена файлов" :
/proc/upyachka/files/futurama.benders.big.score.anivcd.avi -> ../blobs/87c752ef880696e6a2dab87fe88dc5f6  
/proc/upyachka/files/elephantsdream-1920-hd-mpeg4-su-ac3.avi -> ../blobs/9cdec69258b03232cc935c463d9356da

метаданные "пути":
/proc/upyachka/file:///home/bender/video/anime/futurama.avi -> /blobs/87c752ef880696e6a2dab87fe88dc5f6 
/proc/upyachka/http://minilan.net/video/anime/futurama-bbscore.avi -> /blobs/87c752ef880696e6a2dab87fe88dc5f6 
/proc/upyachka/ftp://snafu.com/pub/incoming/1234-futurama-another-boring.avi -> /blobs/87c752ef880696e6a2dab87fe88dc5f6 

метаданные "теги и категории":
/proc/upyachka/tags/bender-big-score -> ../blobs/87c752ef880696e6a2dab87fe88dc5f6  
/proc/upyachka/cat/anime/ -> ссылка на каталог с аниме. Например, так:

/proc/upyachka/revcat/87c752ef880696e6a2dab87fe88dc5f6 -> ../cat/anime
/proc/upyachka/revcat/9cdec69258b03232cc935c463d9356da -> ../cat/anime

 
Фишка в том, что:
1. набор метаданных -- произвольный расширяемый.
2. Все "пути" равнозначны -- это запрос по метаданным, выдаёт блоб или "категорию", множество блобов
3. Всё это кешируется на разных уровнях, 
4. Ссылки: такие, чтобы при перемещении не ломались. Могут указывать "в другой файл-УФК", при этом "сливаются пространства имён", как mount -o bind, UnionFS, PhysFS, итп. 
5. "Рабочее" пространство имён можно "архивировать" : убрать старые блобы в архив, проставить ссылки  на файл-архив (здесь) и само пространство (в архиве)
6. набор метаданных, интерфейсов должен быть в самом файле, чтобы файл был самодостаточный для обработки этого типа файлов.


  


 

блин, форматирование... 

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

 угу, что-то вроде mbox-формата, с заголовками.

 Файл := секция1;секция2;..;секцияN

 СекцияN := заголовок1
            заголовок2
             .  .  .
            заголовокN
            контент-блоб

 заголовокX := текстовая строка, кончается на \n, вида property list:
                 имя_метаданного: значение\n

 набор заголовков "имя_метаданного" произвольный, но есть обязательные 

Content-type: text/plain
Content-length: 666
<далее идёт контент-блоб> , sizeof(blob)=666

наверное полезно сделать "заголовок"  #define:

#define # Content-length:
#define ! Content-type:
! text/plain
# 666
...

и "оглавление", например, для файла ввести Секцию0 с данными о  остальных секциях.

Сама структура в принципе похожа на XML, только в другом виде. Можно завернуть в XML и наоборот, сделать файл "в конверте" вида
<uberml>
 <indexSection0>
    <section1>
 </indexSection0>
 <section1>
  <head>
     <type>text/plain</type>
     <size>666</size>
  </head>
  <body>
        ... encoded(content) ...
  </body>
  </section1>
</uberml>

XML как формат хранения -- избыточен, но интересен тем, что он самодостаточен -- для чтения универсального XML достаточно стандартных reader/writer/возможно ещё схемы XML. Для конвертирования из N входных форматов в M выходных надо написать не N*M со своими reader/writer, а N+M вариантов, из "своего" входного в универсальный, из универсального в "свой" выходной. 

Выходом XML является построенный DOM; если этот "построенный" DOM+интерфейсы работы с данными хранить в соотв. блобе УФК-файла, можно его "скешировать", получить "компилированный" XML.  Лисповые Sexprы тоже хорошо ложаться на идею "кеширования".

Главное, что работа с контентом внутри блобов должна вестись по стандартным интерфейсам и метаданным, на которые есть ссылка (и которые можно засунуть в сам блоб (другой)). 

Если метаданные будут стандартизированы, унифицированы, то становится возможным "сливать виртуальные пространства имён"  таких двух разных UFK.
Так в physfs или в mount -o bind,loop /file1 /mnt && mount -o bind,loop /file2 /mnt.

>метаданные "теги и категории":

/proc/upyachka/tags/bender_big_score -> ../blobs/87c752ef880696e6a2dab87fe88dc5f6  
/proc/upyachka/cat/anime/ -> ссылка на каталог с аниме. 

запрос по категории: /proc/upyachka/cat/anime-bender_big_score
(- = категория без тега, вычитание множеств)

запросы по свойствам вроде /proc/upyachka/bySize/>=/600/Mb
по содержимому /proc/.../byLength/>=/1h:2m, 
по "аннотациям" /proc/.../annot/contains/"сколько лет Бендеру" (выдать файл, с аннотацией(или несколько файлов) содержащей этот текст.

итп любыми лисп-выражениями над метаданными :).