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

Есть юниксвейный метод работы с блобами? Дублирующиеся данные — юниксвей?

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

В общем, я хочу, чтобы в ОС данные были на равных правах с файлами. Со всеми вытекающими последствиями.

ОС предоставляет интерфейс доступа к данным в виде файлов, которые могут быть в виртуальной файловой системе или еще в чем. Но ОС не манипулирует данными.
Но на всякий случай, опишите пожалуйста один небольшой конкретный случай, как вы себе это представляете.
П.С.
Что за динамические файлы? Вы имеете в виду виртуальные файловые системы?

Когда в руке молоток, все проблемы кажутся гвоздями. Типичный антипаттерн.

На костёр паршивца!

Хм. Получается нечто вроде reiser4-плагинов, но мощнее и в юзерспейсе.

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

Что за динамические файлы? Вы имеете в виду виртуальные файловые системы?

Ну да, файлы в них. В /proc таких полно. С тем же успехом можно формировать файлы, в которых результат некоторого запроса к БД. Границы ФС не имеют значения, ln -s никто не отменял.

ОС не манипулирует данными.

Манипулирует, но не так, как с файлами. Поэтому, например, в /proc/<PID произвольного браузера>/fd не видно html с ЛОРом (для ОС это — не файлы, но они же существуют). Поэтому я не могу сделать симлинк на, скажем, звуковую дорожку из видео. Это — задачи не прикладного софта (частично — прикладных библиотек, но почему на десктопе у них нет статуса системных?)
Почему мне нельзя сделать файл, в котором всегда будет «grep <whatever> /var/log/<foobar>» (или select * from foobar_log where whatever=whatever, что уже интереснее), выполняющееся прямо в момент обращения? Скажу сразу: fifo+incrond не сработают.

опишите пожалуйста один небольшой конкретный случай, как вы себе это представляете.

Абстрактный интерфейс к произвольным данным, будь то выборка из БД, нечто из интернета, кусок файла, который <вся эта система> может распарсить (не обязательно парсить каждый файл без запроса), или файл на любой ФС. В юзерспейсе, естественно, но БД может быть и в ядре (примерно как ФС). С возможностью представить любой из этих объектов как файл (не переписывать же весь софт). С возможностью совершать любые действия в момент обращения к данным (собственно, этим можно реализовать простые динамические файлы). С явно определённым API к парсилкам, фильтрам и прочему. Закреплённое где-нибудь в LSB.
Где это может понадобиться:
Очевидно: медиатека, библиотека изображений. Метаданные ко всему этому вполне могли бы храниться в БД, а не в тегах. Проблема поиска полностью решается.
Вариант: протегировать любой файл, лежащий на r/o ФС, и сделать динамический файл, который использует блобом данные оттуда и тегами — данные из БД. Получится >1 файла с одним и тем же блобом данных, это круче, чем дедупликация на уровне ФС. Чуть сложнее: если разрешить динамические файлы с использованием внешних программ, то можно, например, сделать динамический mp3 из данных в flac-файле. С хранением результатов в том самом общесистемном кэше, да. Аналогично с миниатюрами изображений. Почему эти миниатюры — файлы?
Динамический файл с выборкой данных из лога. Вполне возможно, что использующий тот самый общесистемный кэш (чтобы не искать по всему логу, тем более лог может быть частично сжат). Частично реализуемо заменой syslog'а, но если нельзя представить выборку данных как файл (или работать с ней как с файлом/потоком данных) — получаем неunix-вейное неудобное решение.
Где это нафиг не нужно: почти любое недесктопное применение linux и gnu/linux.
Вопрос только в том, кто будет делать подобные фичи для десктопов. На уровне DE есть нечто подобное с vfs, но хочется более низкоуровневого, общесистемного. И без участия fd.o, разумеется.

>Если это кэш, то его по определению можно выкинуть. Осталось определить, где прикладной софт будет хранить кэш + окончательно отучить его паниковать при удалении кэша + определить, где будет демон, следящий за ресурсами и приоритетами кэша + сделать стабильный API, чтобы убить идею хранения кэша в файлах.
Если его можно выкинуть по любому поводу, то его можно не хранить. Я же спросил как будет проходить инвалидация кэша.
А еще, смысл хранить кэш в какой-то ФС на диске, если есть вещи типа membase, которые хранят кэш в памяти и файлах, что быстрее.

(частично — прикладных библиотек, но почему на десктопе у них нет статуса системных?)

Потому что никто не будет пихать лишнее в системные либы.

Почему мне нельзя сделать файл, в котором всегда будет «grep <whatever> /var/log/<foobar>» (или select * from foobar_log where whatever=whatever, что уже интереснее), выполняющееся прямо в момент обращения? Скажу сразу: fifo+incrond не сработают.

Зачем это нужно? Такой файл можно сделать с помощью VFS, и без особых сложностей кстати. Только это в принципе не особо нужно. "./файл" и «cat файл» не сильно отличаются, чтобы городить сложности.

Очевидно: медиатека, библиотека изображений. Метаданные ко всему этому вполне могли бы храниться в БД, а не в тегах. Проблема поиска полностью решается.

Как она решается то? Полнотекстовый поиск в реляционной не иерархической БД та еще задача. А для поиска через внешний индекс его можно сделать хоть из дизасемблированного кода программ.

Вариант: протегировать любой файл, лежащий на r/o ФС, и сделать динамический файл, который использует блобом данные оттуда и тегами — данные из БД. Получится >1 файла с одним и тем же блобом данных, это круче, чем дедупликация на уровне ФС.

Можно конечно, но зачем? Как и когда при получении файла эти данные вообще пихать в базу то?
Получается мы получаем данные из интернета/CD/торрентов с нужными тегами, льем теги в бд, и потом юзаем какую-то еще одну ФС для доступа к этим тегам?

сделать динамический mp3 из данных в flac-файле. С хранением результатов в том самом общесистемном кэше, да.

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

Аналогично с миниатюрами изображений. Почему эти миниатюры — файлы?

Потому что десятки тысяч миниатюр читать из базы неудобно. А если еще приделать индексы и права пользователей, то оно будет занимать сотни мегов, и поиск по этой базе не будет особо быстрым. А еще вопрос инкрементальных бэкапов, восстановление при повреждении таблицы(не такая уж редкость), И тот же вопрос сортировок, они тоже в не иерархической БД не быстрыми будут.

П.С.
Я все-таки не понял структуру полей в таблице. Там будет таблица на каждый тип файла что-ли?
И кстати, каким образом она будет заполнятся для всяких новых типов файлов? Не хранить же в libc формат тегов для всяких проприетарных mp3.

Меня больше интересует почему IM-клиенты до сих пор не умеют хранить логи в SQLite, в едином для всех клиентов формате.

>Там будет таблица на каждый тип файла что-ли?
На распространённые — да, если её попросить. Это же в дополнение к ФС, не как замена.

И кстати, каким образом она будет заполнятся для всяких новых типов файлов? Не хранить же в libc формат тегов для всяких проприетарных mp3.

Внешним софтом. Заполнение — разовая операция, не стоит хранить её код в RAM.

Если его можно выкинуть по любому поводу, то его можно не хранить.

Пример: кэш браузера, кэш шрифтов, кэш thumbnail'ов, ccache Их можно выкинуть по любому поводу, но с ними быстрее. Поэтому без повода выкидывать не стоит.

А еще, смысл хранить кэш в какой-то ФС на диске, если есть вещи типа membase, которые хранят кэш в памяти и файлах, что быстрее.

Я о чём? Только ничего не умеет этот membase.

Зачем это нужно?

Чтобы можно было подсунуть любой софтине, ожидающей файл, этот самый динамический файл. Пайпы — не объект первого класса в linux, к сожалению.

Можно конечно, но зачем? Как и когда при получении файла эти данные вообще пихать в базу то?

Как и когда при получении файла по http в ФС пихаются данные «дата создания», «владелец», «права доступа»? ФС — тоже БД, пусть и менее гибкая.

Получается мы получаем данные из интернета/CD/торрентов с нужными тегами, льем теги в бд, и потом юзаем какую-то еще одну ФС для доступа к этим тегам?

ФС — виртуальная. Или есть более вменяемый метод предоставить доступ к данным софту, который не в курсе, что кроме файлов что-то бывает?
Файлы на реальной ФС можно представить как выборку нескольких полей виртуальной. Естественно, это будет касаться только отдельных файлов. Если при выборке идёт трансформация поля — это опционально кэшируется.

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

А возможность запустить внешнюю программу, которая всё сделает, и представить её вывод как файл — не помешает. И от этой возможности библиотека жирной не станет.

Потому что десятки тысяч миниатюр читать из базы неудобно.

А откуда удобно? Тем более что мешает хранить путь к файлу в традиционной ФС?

А если еще приделать индексы и права пользователей, то оно будет занимать сотни мегов

Какие индексы у миниатюр?

права пользователей

Уже есть у данных. Зачем дублировать это для метаданных (которыми миниатюры, внезапно, являются)?

А еще вопрос инкрементальных бэкапов, восстановление при повреждении таблицы(не такая уж редкость)

Сломалось — можно сгенерировать заново. Кому придёт в голову бэкапить кэш?

И тот же вопрос сортировок, они тоже в не иерархической БД не быстрыми будут.

Они и в иерархической БД быстрыми не будут. И задачи «отобразить миниатюры совсем всего + отсортировать» изначально не стоит.

И да, от libc просто требуется, чтобы кроме fopen() было нечто вроде getdata(). Более высокоуровневые вещи — в других библиотеках.

>Уже есть у данных. Зачем дублировать это для метаданных (которыми миниатюры, внезапно, являются)?
Есть таблица с 1000 миниматюр. Права доступа только у основных файлов. Заходи в таблицу кто хочет, смотри миниатюры кто хочет?

Сломалось — можно сгенерировать заново. Кому придёт в голову бэкапить кэш?

Это я не про кэш имел в виду, просто не там написал. Если теги хранить в базе она ведь тоже может сломаться.

Они и в иерархической БД быстрыми не будут. И задачи «отобразить миниатюры совсем всего + отсортировать» изначально не стоит.

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

Как и когда при получении файла по http в ФС пихаются данные «дата создания», «владелец», «права доступа»? ФС — тоже БД, пусть и менее гибкая.

То есть приделываем виртуальную файловую систему к реальной?

Я о чём? Только ничего не умеет этот membase.

Не распарсил.

Внешним софтом. Заполнение — разовая операция, не стоит хранить её код в RAM.

Не разовая. Она происходит постоянно, особенно при использовании того же браузера.

П.С.

Мы отошли от вопроса. Я так и не понял, зачем это интегрировать в системные либы, а не сделать на уровне dbus, X.Org или udev?

>Есть таблица с 1000 миниматюр. Права доступа только у основных файлов. Заходи в таблицу кто хочет, смотри миниатюры кто хочет?
Есть таблица с соответствиями «права и прочие метаданные-inode» (она, внезапно, в ФС). Есть таблица «inode-миниатюра». Есть правило, по которому проверяются права. В итоге получаем одну запись о правах на файл. В случае с ФС записей о правах 2 (а заодно мусорные записи о датах создания/модификации/доступа/whatever).

Если теги хранить в базе она ведь тоже может сломаться.

ФС сломаться не может?

То есть приделываем виртуальную файловую систему к реальной?

Именно. Поэтому я и сказал: это — уровень vfs (не ядерной, той, которую велосипедят в *каждом* DE).

Скорость растет в геометрической прогрессии с увеличением вложенности.

Скорость выборки всех элементов — нет. Промежуточные выборки никто не мешает хранить как кэш.

Не распарсил.

Напомни мне реализации браузера, fontconfig и file manager'а, которые юзают memcache под кэш.

Не разовая. Она происходит постоянно, особенно при использовании того же браузера.

Нет, разовая. Никто не обязывает делать это с каждым файлом при его появлении. Умная реляционная БД и сверхтупая — 2 отдельные сущности, которые стоит добавить к уже существующей иерархической БД.

Я так и не понял, зачем это интегрировать в системные либы, а не сделать на уровне dbus, X.Org или udev?

Для десктопа dbus и udev — системные либы. И системные сервисы. И на этом уровне, в общем-то, и стоит реализовывать основную логику. Но API, по которому подключаются все навороты, должно быть достаточно стандартизовано и присутствовать на десктопах.
В libc достаточно будет низкоуровневого интерфейса к трём БД (тупой key-value, реляционной и иерархической) вместо одной (иерархической).

>Есть таблица с соответствиями «права и прочие метаданные-inode» (она, внезапно, в ФС). Есть таблица «inode-миниатюра». Есть правило, по которому проверяются права. В итоге получаем одну запись о правах на файл. В случае с ФС записей о правах 2 (а заодно мусорные записи о датах создания/модификации/доступа/whatever).
Я не про то, я про то, что либо к таблице миниатюр имеет доступ только рут, либо ее может взять кто хочет.

ФС сломаться не может?

Может, но ФС с этой точки зрения надежнее. Плюс в данном случае всё-равно надежность виртуальной файловой системы = надежность базы * надежность ФС.

Скорость выборки всех элементов — нет. Промежуточные выборки никто не мешает хранить как кэш.

Чтобы ее запихнуть в кэш, ее надо получить сначала.

Нет, разовая. Никто не обязывает делать это с каждым файлом при его появлении.

О, дайте угадаю, еще раз кэш да? Может выкинуть все, и этот кэш вместо всего юзать, если он такой универсальный и быстрый?

В libc достаточно будет низкоуровневого интерфейса к трём БД (тупой key-value, реляционной и иерархической) вместо одной (иерархической).

Интерфейс доступа к реляционной БД будет размером с половину libc. А key-value при отсутствии хранения в памяти и шардинга, ну ничем не отличается от хранения файлов в одном каталоге.

>Может, но ФС с этой точки зрения надежнее.
В смысле? Иерархическая БД надёжнее, чем любая другая?

>Интерфейс доступа к реляционной БД будет размером с половину libc.
Достаточно открытия произвольной записи из произвольной таблицы по некоторому inode + поддержки простейших фильтров. SQL необязателен.

>О, дайте угадаю, еще раз кэш да? Может выкинуть все, и этот кэш вместо всего юзать, если он такой универсальный и быстрый?
Конечно. Для десятка-другого файлов — почему бы и нет? Повторяю: я не думаю, что это должно заменить всю ФС.

ФС не БД в полном смысле этого слова. Вы не можете хранить свою базу не используя ФС, поэтому надежность ФС всегда будет выше чем у базы. И да, журналируемые ФС надежнее так как они готовы к внезапному выключению компьютера например, а транзакции в такой ситуации не отработают.

>ФС не БД в полном смысле этого слова.
Нет, БД. Пусть и не реляционная. ФС сложнее key-value БД.

журналируемые ФС надежнее так как они готовы к внезапному выключению компьютера например

Кто мешает сделать журналируемую БД?

Вы не можете хранить свою базу не используя ФС

Ксати, почему в линуксе нет поддержки общесистемной БД для «кое-чего», расположенной на отдельном разделе (либо LVM, с автоуправлением размером LV), интеграцией юниксовых прав и стандартизованным API для доступа?

x3al *** (06.05.2011 22:17:59)

>Достаточно открытия произвольной записи из произвольной таблицы по некоторому inode + поддержки простейших фильтров. SQL необязателен.
То есть нужны таблицы с поддержкой типов, хранение их на диске, индексы(не перебирать же все строки), полнотекстовый поиск. Наверное еще хотелось бы объединения(JOIN), иначе смысл в связи двух таблиц отпадает. А для того, чтобы удаления в других таблицах проходили автоматически, желательны еще внешние ключи. Для обеспечения уникальности еще нужны уникальные индексы.

>Конечно. Для десятка-другого файлов — почему бы и нет? Повторяю: я не думаю, что это должно заменить всю ФС.
Для десятка-другого файлов никто не будет это пилить.

>Нет, БД. Пусть и не реляционная. ФС сложнее key-value БД.
key-value не БД, а storage. База данных подразумевает схему описанную на формальном языке.

Ксати, почему в линуксе нет поддержки общесистемной БД для «кое-чего», расположенной на отдельном разделе (либо LVM, с автоуправлением размером LV), интеграцией юниксовых прав и стандартизованным API для доступа?

А управлять вы как будете секторами на диске, фрагментацией, выделением кластеров?

>А управлять вы как будете секторами на диске, фрагментацией, выделением кластеров?
Как будто сейчас oracle и mysql не умеют raw partition.

>Для десятка-другого файлов никто не будет это пилить.
Да ну? /proc для десятка-другого файлов запилили. Оно достаточно похоже на это, хотя и находится в kernel space.

А binary log они хранят там же?

Ну если вам это нужно, то докажите это теперь тем, кому это нужно и кто это может сделать :) Ну или сделайте сами, api для VFS не особо мудреный.

А как же регулярное уплотнение?

да, я тоже считаю что традиционная древовидная структура ФС - мощнейший тормоз прогресса.

Было на Microsoft Developers Conference 20 лет назад

А? я то думал всего 8 лет назад. У Microsoft это называлось WinFS: http://www.oszone.net/1280/ http://www.megaplus.ru/clause/win_fs.htm http://www.tomshardware.com/reviews/winfs-file-system-windows-longhorn,645.html

>Видеофайлы будут разбиваться на блоки по ключевым кадрам. При чтении - запрос на нужный блок + несколько блоков наперед для кэширования (сейчас то же происходит на ФС, разве не так?).

Вытаскивание бинарных блобов из БД занаятие само по себе тормознутое (т.к. все оборачивается в сетевой стек), а если запустить, скажем, файловый монитор и посмотреть на активность обращения к файлам (когда 50 запросов в секунду уже не редкость) - любому зрдавомыслящему человеку станет ясно, что ресурсов оно будет жрать просто немеряно