LINUX.ORG.RU

«Storage» - будущее файловых систем?


0

0

Проект Storage разрабатывается Сетом Никеллом (Seth Nickell), ответственным за usability в GNOME 2.x. Storage представляет из себя систему для хранения документов, базирующуюся на PostgreSQL. Текущая реализация, написанная для GNOME 2.x имеет ряд приятных возможностей, в том числе поддержку естественных языков и прозрачную работу по сети. При этом Storage сохраняет обратную совместимость с GnomeVFS и имеет простой интерфейс прикладного программирования (API).

>>> Подробности

★★

Проверено: ivlad

ну наконец-то, давно пора какой-нить dbfs появится, надеюсь это первый шаг.. может наступят времена когда mp3 tag и аудиопоток будут хранится как поля в записи

anonymous
()
Ответ на: комментарий от anonymous

> Ура спижживанию WinFS из Longhorn!

... которое тоже не является гением мысли Microsoft а "позаимствовано" из IBM AS/400.

ivlad ★★★★★
()
Ответ на: комментарий от anonymous

кто у кого с3.1415...здил

2 anonymous (*) (2003-09-07 05:13:52.878591):

> Ура спижживанию WinFS из Longhorn!

Ура с....иванию translators из Hurd!

Dselect ★★★
()

а можно обьяснить простому смертному что это такое и чем это для него будет хорошо?

anonymous
()

Я не пойму - ведь вроде рейзер тоже стремится к тому же самому ? Зачем изобретать еще один велосипде когда можно довести до ума существуюший ?

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

Идея хранить файлы в базе данных далеко не нова. МS заявила о разрабатываемой возможности. Разработчики Linux-решений тоже заявили.

Поглядим у кого получится лучше.

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

Собственно уже догоняет. Не зря ж они специальную группу по наблюдению за Linux сделали. :)

Bill-Gei-t-s-s-s
()

2 anonymous (*) (2003-09-07 05:13:52.878591)
Что касается WinFS в Longhorn, то, если я не ошибаюсь, на какой-то последних своих конференции Microsoft приоткрыла, что такое WinFS.
И оказалось, что это всего-навсего обыкновенная NTFS с прикрученной по умолчанию службой индексирования.
Что несколько отличается от того, что делает Рейзер и что есть в AS400 (или как там оно теперь называется ;)
Точных ссылок не помню, читал в журнале.

anonymous
()

Так объясните все-таки глупенькому - это те же самые идеи что и в рейзере (заявленные, но еще не реализованные ?)

anonymous
()

> Ура спижживанию WinFS из Longhorn!

Блин, точно не помню, но такие идеи явно не связаны с мелкомягкими - существует масса наработок с подобным механизмом, и к мелкомягким они отношения никакого не имеют...:)

anonymous
()
Ответ на: комментарий от anonymous

Какая разница у кого, главное что спижжено. А реализация затянется на годы - как все гпльное.

Finder
()

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

anonymous
()

проблема в том, что кроме тормозов ничего нового к традиционным файловым системам с поддержкой атрибутов и разделяемых по NFS/SMB (и уж тем более комплексным SAN решениям) эта идея не принесет.

поэтому будущим тут и не пахнет. очередная идея из области "трехмерного пользовательского интерфейса" ...

Murr ★★
()

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

С другой стороны - это направление ориентируется на десктопное применение, не серверное.

Korwin ★★★
()

Хм. А вот интереснее было бы сделать ФС как реализацию стандартов OMG. таких как MOF и CWM. Вот это реально интересно было бы, да и на голову выше того что они собираются сделать. Темболее что модели MOF можно хранить где угодно, хош XML/XMI хош БД. Это становится уже не важно :)

anonymous
()
Ответ на: комментарий от Korwin

Korwin: Без сомнения. Но никаких свежих идей я не вычитал (может плохо читал). Нити в файлах были еще в HFS (в частности там иконки хранились), в Win они есть и на NTFS, причем есть несколько недоработанный (но все же) механизм их индексирования. В Linux есть XFS, где EA уже почти можно использовать.

Murr ★★
()

2Murr
полностью согласен
IMHO делается это все побольшей части для маркетинга и на руку производителям hardware.

Dead ★★★★
()

TO Dead

Ты свам то понял что глупость сказал ? :)

yurykosh
()

Ну может и не совсем корректно сказал...
особенно по поводу маркетинга :)
сорри
просто последнее время начинает плющить от этих всех новомодных штучек в красивой этикетке.

Dead ★★★★
()
Ответ на: комментарий от Dead

Dead: угу... :) пока софт пишут производители hardware без работы не останутся :))

Murr ★★
()

А на Slacware оно будет работать? )))) По-моему это не так удобно как кажется разработчикам этой ботвы.

Shaman007 ★★★★★
()

Я читал про похожую разработку для KDE. Она еще в зачаточной форме. Суть не сколько в форме хранения данных, а в способе их поиска и сохранения. Предлагается пересмотреть фундаментальный принцип почти всех современных файловых систем - иерархической организации, и перейти к более интуитивной и понятной человеку. Грубо говоря, когда мы ищем наш договор на поставку болтов М6, мы не лезим в каталог C:\My Documents\dogovora\bolti\m6\ где, как мы ожидаем, должен лежать файл с договором dogBoltM6-23.txt, а вводим критерии поиска (типа: договор, болты, Иван Иванович, до 1 числа прошлого месяца) и получаем подпадающие под эти критерии информацию. Таким образом даже неряшливый лобзик, который не обременяется раскладыванием своих файлов по подкаталогам сможет легко отыскивать информацию.

аи

anonymous
()

Да, идея не понятна. Кажется где-то проскакивала статейка, про то, что на современных винтах столько данных хранится, что пользователям пора обзаводиться локальными поисковиками... ;-)

anonymous
()
Ответ на: комментарий от anonymous

Это называется "N-мерное хранилище данных". Не сказал бы, что она во всех случаях более интуитивна и понятна для человека и, конечно, не является панацеей. В некоторых случаях может только увеличить неразбериху. А вообще, красиво:

/home/user/documents/[type=report,date='01-09-2003']/

balu
()

ваще пора делать фс примерно как в пальме. файлы - это пережиток *никс и вин*

я правда еще не придумал как именно, но делать надо

anonymous
()

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

anonymous
()

Я сейчас тоже сильно задумался над такой системой. Посмотрел уже закрытый Ефрат. Там как хранилище так и ворфлоу. Я пока решил реализовать это только в виде хранилища (воркфлоу потом вполне можно доднлать, но он зависит от конкретной организации). Смысл таков: Есть сервер он по XML-RPC получает запросы get, put, search. Вот и все. а в том-же ворде и ОО вместо кнопки сохранить выводим кнопку которая запускает макрос, который сохраняет все в temp и спрашивает пользователя о полях которые обязательно нужно вбить. Потом документ с полями улетает на сервер. FS тут нет....

Может кто заинтересован, может можем вместе работать, а то одному сложновато такое тянуть.

dem ★★
()
Ответ на: комментарий от balu

> /home/user/documents/[type=report,date='01-09-2003']/

в таком виде, как ты написал, это уже было. в OpenVMS.

ivlad ★★★★★
()

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

ps Storage is part of a larger design for a new desktop environment...
... replace the traditional filesystem with a new document store.

Ключевые слова. Очень смахивает на SharePoint :-) Здорово, но причём тут замена традиционной ФС вообще на ФС-БД?

PitStop
()

А кто чтонибудь свободное типа шарепоинта знает?

dem ★★
()

dem: по XML-RPC получает запросы get, put, search
Есть более простой вариант. get и put уже довольно хорошо обслуживаются разными файловыми системыми(сетевыми или нет). А search - это работа для простой (find|locate)-подобной программы с поддержкой аттрибутов, анализа содержимого нескольких типов файлов и кеширования результатов.
В таком случае нужно только добавить к клиетнскому UI диалог "найти по чему-то-там".

И вообще, все эти "хранилища" сильно похожи на:
#!/bin/bash
select file in $(find ... | xargs grep ...) ...

IMHO.

DonkeyHot ★★★★★
()

Согласен с PitStop. Зачем все это нужно? Боюсь, все это будет походить на какую-то advanced помойку.

anonymous
()

2DonkeyHot Ну насчет get put я согласен. Просто можно давать ссылку на то где хранится документ реально в атрибуте скажем URL. А вот насчет скрипта не согласен. Это не масштабируется. Причем тут еще есть фишка. У каждой организации несколько иные требуются аттрибуты. Опять-же неплохо-бы хранить версии документов. Тоесть я как админ должен уметь задать как минимум 1) Схему атрибутов для того или иного МИМЕ типа, указать их обязательность тип и перечень возможных значений (DTD напоминает?). 2) ACL и аудит. Кстати на эту тему очень заинтересовался FramerD т.к. реляционные БД не обеспечивают необходимой гибкости с сохранением скорости. Никто не подскажет ресурсов с кикстартом по этой нереляционной БД. А то у меня она лезет на их сервер хоть ты тресни...

dem ★★
()

2anonymous (*) (2003-09-08 11:43:49.515863) С пальмой помойки не получается почемуто? А там похожая система и объем занимает меньший...

dem ★★
()

2 dem (*) (2003-09-08 11:54:32.657259)
> ... и объем занимает меньший...

Ключевые слова!

PitStop
()

с пальмой не получается помойки потому как там для помойки хрен развернешься, даже 256 мб маловато для нормальной помойки

но в то же время пальма - это шаг вперед в сравнении с мультитредовыми-журналируемыми-индексированными-продвинутыми нтфс и других рейзеров

anonymous
()

проититит

anonymous
()
Ответ на: комментарий от dem

>А вот насчет скрипта не согласен. Это не масштабируется.
А почему, собственно? Я этой проблемы пока не вижу.

>ACL и аудит ...
Первое во многих ФС есть, второе - просто реализуется.

>версии документов ...
А это действительно требует другого протокола. Кстати, его можно реализовать используя (протокол) сетевой ФС в качестве транспортного, ограничившись модификациями диалогов открытия и сохранения файла:-)

>У каждой организации иные требуются аттрибуты...
>Схему атрибутов для того или иного МИМЕ типа,

Тут нужно различать 2 уровня решений.
1. Каждый(или абсолютное большинство) документов, используемого в организации, имеют различимый программой тип. Этого на обычных оффисных програмках(типа MSWord, excel, etc.) не получить - для этого нужен редактор, _навязывающий_ структуру документа. В таком случае все _важные_ аттрибуты у документа внутри - и тогда да - документы должны лежать в БД со своими сложными алгоритмами поиска и пр...

2. При обычном же подходе с неструктурироваными документами множество _осмысленных_ аттрибутов и практически не отличается для разных типов документов (ввиду неразличимости оных) и содержит, может быть, до 10 аттрибутов. В этом случае всякие FramerD - пушкой по воробьям.

Конечно, можно задаться целью качественно организовать всякий документооборот на нынешних оффисных пакетах - но тогда _человеку_ придется следить за соответствием информации о документе(аттрибутов) содержимому оного. Что, IMO, чревато боком:-)

DonkeyHot ★★★★★
()
Ответ на: комментарий от anonymous

>с пальмой не получается помойки потому как там для помойки хрен
>развернешься, даже 256 мб маловато для нормальной помойки
>но в то же время пальма - это шаг вперед в сравнении с
>мультитредовыми-журналируемыми-индексированными-продвинутыми нтфс и
>других рейзеров

Ребят сил моих нету, вы наверное под PalmOS не писали ничего.
Структура хранения записей в PalmOS никакой не шаг
и не вперед просто просто бл**ь, еб***е архитекоры
PalmOS почемуто бл**ь решили что большинство
программ для Palm будут работать с микроскопическими записями
и решили "помочь" программистам - сделали убогие
БД и не сделали файлы вообще.
PalmOS не поддерживает ни полей записей ни поиска в БД, запись
максимум 64k и это просто набор байт без типа.
Особенно удобно этим еб***тым "шагом вперед" пользоваться если нужно
сохранить картинку или текст размером > 64k.

За исключением вышесказанного базы данных в PalmOS
это конечно прорыв по сравнению
"мультитредовыми-журналируемыми-индексированными-продвинутыми
нтфс и другими рейзерами"

Troll
()

>еб***е архитекоры PalmOS почемуто бл**ь решили что большинство программ для Palm будут

аха, был еще както один перец, который заявлял "640кб хватит всем и каждому, и пусть никто не уйдет!"

>За исключением вышесказанного базы данных в PalmOS

дык никто и не говорит: "пальму в лонгхорн!" хотя и пень4 все еще поддерживает x86 real mode сегментную адресацию :)

anonymous
()

2Troll Не матюгайся писали. В принципе 1) Такая организация удобнее для энд-юзера 2) Удобнее для меня т.к. я еще ни казу не слыщал чтобы в моих программах на пальме - "документ пропал". Ограничение 64 kb там не само-собой появилось - проц такой... Вобщем к идее это никаким боком не относится...

2DonkeyHot Вобщем вы меня пока не убедили. Скрипт не масштабируется потому-что он будет бегать по всей FS в поисках. А тот-же FramerD использует хэши. И я легко могу выдернуть все фреймы ссылающиеся на жданный или меющие в слоте нужный мне параметр. Атрибутов далеко не 10 их от 1-URL до бесконечности и не обязательно все вводятся в данном случае реляционные БД не катят (можно сэмулировать с помощью 3-х таблиц но это гемморой).

Вобщем как я вижу мало кто сталкивался с ордами недоюзеров которым больше SonyPS давать нельзя Ж-) это радует, но огорчает что я сталкивался...

dem ★★
()

2 dem (*) (2003-09-08 15:08:22.647596)
> Вобщем как я вижу мало кто сталкивался с ордами недоюзеров которым больше SonyPS давать нельзя Ж-) это радует, но огорчает что я сталкивался...

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

PitStop
()
Ответ на: комментарий от dem

2dem
>1) Такая организация удобнее для энд-юзера
Такая организация не имеет никакого отношения к энд-юзеру
он про нее не знает. Все что он видит это список имен
документов, картинок, книг, e-mail-ов etc а уж в чем они там
хранятся дело OS и программистов, а вот как раз программистам
очень не удобно этой самой БД пользоваться.

>2) Удобнее для меня т.к. я еще ни казу не слыщал чтобы в моих
>программах на пальме - "документ пропал".
Если каждый день бекап по HotSync делать как это
обычно бывает с пользователями Palm то действительно
сложно что-то потерять независимо от того как
именно хранятся данные =)

>Ограничение 64 kb там не
>само-собой появилось - проц такой...
Гхм может быть я тебя удивлю но я таки нписал
FS поверх палмовской БД с поддержкой файлов
_любой_ длины и даже ни разу не вспоминал пока писал
какя у процессора разрядность.
Может дело все таки не в прцессоре?

>Вобщем к идее это никаким боком не относится...
Я и говорю что палмовские БД ни к каким идеям
никаким боком не относятся.

anonymous
()
Ответ на: комментарий от dem

>Скрипт не масштабируется потому-что он будет бегать по всей FS

Если ему не приделать кеш ответов(бд. с аттрибутами):-) Не понимайте меня буквально - я не считаю, что это нужно делать это на sh+find+grep (хотя это возможно). Я пытаюсь сказать, что данная задача решается более просто(по сравнению с реализацией всего с нуля) - используя готовые примитивы доступа к файлам и небольшую базу данных с содержимым типа (аттрибут,значение,файл) и переделывая 2-3 диалога+функции в "основных" офисных программах.

Если только у Вас нет больших обьемах хорошо структурированых данных :-(что есть довольно редкая ситуация)-:. В этом случае Вам действительно нужно более качественное решение(тот же FramerD) - но Вас тогда не должно сильно беспокоить интеграция с office-ами - по причине плохой(пока) структурированости данных, ими поставляемых.

>И я легко могу выдернуть ... . Атрибутов далеко не 10
Это вторая причина моих возражений. Вы то можете. Но трудно представить, чтобы большАя часть пользователей (а тем более "недоюзеров") смогла бы правильно формулировать запросы к этой самой FramerD пользуясь большим числом параметров. Сложность в том, чтобы заставить их помнить, что какой параметр обозначает, и уметь излагать свои желания на понятном системе языке.

DonkeyHot ★★★★★
()

2Shaman007 (*) (2003-09-07 21:15:18.183109)

К проекту "Соломон" имеешь кокое-либо отношение?

:-)

anonymous
()
Ответ на: комментарий от dem


2dem (*) (2003-09-08 11:54:32.657259):

> 2anonymous (*) (2003-09-08 11:43:49.515863) С пальмой помойки не
> получается почемуто? А там похожая система и объем занимает меньший...

В палме - помойка натуральная :) Просто её не видно до поры до времени.

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

А поиск там вообще зело весело - ось обращается к каждой программе по очереди - "А нет ли у тебя, милайа, записей с такой-то строчкой унутре?" :-)

Знаешь, если в тех же виндах дальше эксплорера и "My Documents" не лазить - но на первый взгляд тоже помойки нет. Хотя мы же знаем что там на самом деле ;)

Всё это (палмы и прочая ботва) не имеет никакого отношения к теме.

ИМХО система "Storage", как и все аналогичные, будет полезна до первого неизвестного системе формата файла.

Dimentiy ★★
()

Re:

2Dimentiy Вот потому и обращается что так не будет неизвестных ей форматов. Вобщем я думаю я понял на чем основано ваше скептическое отношение.

А вот что конструктивного вы можете сказать? Может есть какие идеи по уменьшению вселенского хаоса каким стали многие FS на HDD?

dem ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.