Гавно эта ЖыЭфЭс, ацтой полнейший... Нафига она нужна, когда есть ЫксЭфЭс от Силиконофф?!

Pre патчи

На девелоперские ядра pre патчи руками поправлять нужно что-ли? Там просто они не накладываются. Пытаюсь положить, разумеется, на 2.5.5, (начиная с pre1). Это самое 2.5.5 в свою очередь доведено патчами с 2.5.0, то есть никаких проблем, а сейчас 8( У кого работает?

-- Greeder

Все получилось. Сделал symlink на каталог linux-2.5.5 и именем "a" Кстати, зачем патчи так сделали?

--Greeder

2Greeder: Надо patch -p1 делать.

>>Это уже третья по счету журналируемая файловая система в ядре.
Как это третья? ext3 знаю что включили, сам пользую.
Или XFS уже тоже в 2.5.x?

Третья - reiser JFS, кстати, вполне заработал ;)

--Greeder

Хммм я что-то в недоумении. Такая штука в ядре как drm для SiS не компилится ни в stable ни в unstable. В 2.5.6-preX его вообще убрали (в 2.4.19-preX помойму тоже но не уверен). 2.5.5 не собирается, 2.5.6-preX не собирается. Собралось только 2.5.5-dj2. Что такое "вытесняемое ядро" я почувствовал когда xmms начинает тормозить и тянуть когда открываются какие-то большие проги (look&feel прям как в винде). А еще из сюпризов другой формат input core devices я впервый раз не заметил так собрал ядро без поддержки клавы ;)

Вообще-то не третья, а четвёртая.

Вообще-то четвёртая.
1) ReiserFS
2) XFS
3) ext3
4) JFS

Они считают те, которые включены в mainline. Для меня XFS включен и в 2.4 и в 2.5. :-)

А вообще-то из всех их по-моему самая перспективная - XFS.
Главное чтобы не бросили ее разработку ;)

2Eugeny Balahonov: хммм, а почему именно XFS, а не RaiserFS? Обоснуй, интересно...:)

а там твои любимие extended attributes есть с рождения. :)

Вопрос по xfs: Есть _работающий_ сервер (стоит ext3fs), можно ли перевести на xfs "на лету" ?

2anonymous (*) (2002-03-04 09:31:16.0): Переконвертировать - нет. Только создать другой раздел (xfs), закопировать туда данные остановить сервер, перемонтировать раздел и запустить сервер. Кстати, любые утилиты переконвертации требуют размонтированного раздела. И еще Partition Table нужно править!

Плохо, Размонтировать на несколько минут можно, а вот создать другой раздел - не получится объем большой (RAID)? бекапить на ленту и восстанавливать затем - слишком долго :(( Ни кто не в курсе, GNU Parted конвертить в xfs умеет ?

Я в курсе, что он конвертить не умеет вообще. То есть в принципе ?то возможно, но пользователю такой возможности не дано.

1) ACL

2) С квотами дружит

3) realtime subvolume

2Antichrist: но насколько я понимаю не многопоточна всеже? Или я что-то пропустил?

На oss.sgi.com/projects/xfs/todos.html написано, что планируется: "5. Multi-threaded direct I/O writes, ..., Planned release: 1.2"

2anonymous (*) (2002-03-04 12:53:03.0): По моему опыту в таких делах, когда нужно быстро что-то поменять, без backup и т.д. очень хорошо работает закон Мерфи. По этому чисто по-человечески не советую переконвертировать. Всякое может случится и наверняка, какая-то гадость всплывет.

2Settler: эээ... я вообщем говорил о multiple data stream per file..;) Блин, с этим переводом терминов вечьно путаница...:(

> multiple data stream per file
Лишено смысла в ОС с не-объектной идеологией хранения данных.
Идиотский костыль, по уровню идиотизма этот костыль может превзойти только RMS$* из VMS.

Скорее всего зачатки объектной идеологии появятся первыми в ReiserFS v4, которая должна выйти в сентябре. Интересна так же Microsoft-овская разработка на эту тему - разумеется, не NTFS-ный костыль, а нормальная попытка организации БД объектов.

Думаю, будущее всё-таки в единоуровневом объектном доступе к данным, как это происходит в PICK и OS/400.

2AffreuxChien: ну имхо в RaiserFS именно вариант multiple data stream per file и реализуется... По крайней мере наколько я понял их описание...
Про AS/400 - да, хорошо... но это уже не юних и вообще на "классические", привычные ОС малопохоже... Так что это конечно наше светлое будующее, но имхо довольно далекое будущее... А как промежуточный вариант на пути к этому светлому будующему многопоточные FS имхо очень хороши...

> А как промежуточный вариант
Нет проку в "чуть-чуть беременности"

Вот если
echo Hello world >> somedatafile
и
select txt from somedatafile where txt like '%wor%'

и select objectname from somedirectory where modification_date = CURRENT_DATE

и самое главное -
select objectname, objecttype from somedirectory where objecttype in (file, program, queue)

:)

2AffreuxChien: а что мешает один поток, типа системный, отвести на оаисание форматов других потоков? Ну а дальше все как ты описал имхо и выйдет... При наличае нужных либ разумеется...

А зачем искусственно плодить сущности? Распознать формат - это задача user-space проги.

> а что мешает один поток, типа системный, отвести на оаисание форматов других потоков?

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

б) ссылки на принадлежность пакету с обеспечением ссылочной целостности.
в) внешней атрибутики

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

Например:
Есть какой-то документ. Нахрена помнить, куда его запрятали? У документа есть атрибутика - тема, содержимое и т.п.

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

Ну, а такие мелочи, как организация того или иного типа объектов - не важны.

2AffreuxChien: ну вообщем да - делить память это глупость... FS - костыль. Есть хранилище обектов, когда нужен объект - начинаем его пользовать, когда станивится не нужным - прекращаем. Сорхранение на диск и т.д - забота менеджера объектов, нас оно не касается. Никакой тебе оперативной, постоянной поамяти и т.д. - есть просто память. Т.е. ОЗУ превращается в еще один уровень кеша, и проги ее как бы не видят...
Все это прекрасно, только с этим подходом надо забыть юникс как страшный сон...

"и самое главное - select objectname, objecttype from"
Объясни, плз, мне неразумному - а на хрена ???? Нет, не "на хрена select from", я то вовосе не против, что б пользователь ни про какие файлы ничего не знал и все такое... Но на хрена это в FS тащить то ???

"тупых поточных файлов"
А винчестеры уже инфу в виде бд хранят ??? :-))))

"Они не обеспечивают современных требований к каталогизации информации."
Прости, а ты что, каталогизируешь информацию в файлах ??? :-)))))))))

"Есть какой-то документ. Нахрена помнить, куда его запрятали?"
Ну а фс то тут при чем ???

Тебе не кажется, что ты слегка подзабыл ГЛАВНОЕ назначение фс - предоставлять аппликухам интерфейс для сохранения данных (в наиболее общем и классическом случае, про всякие /proc и /devfs пока не будем :-))) ??? И чем сложенее система - тем она хуже, разумнее иметь иерархию из нескольких слоев систем. С тем же документом - создать бэдэшку хранящую инфу по файлу, интегрировать ее с софтом (с десктопом каким-нить) и все. Если она крякнет, то я хоть и потеряю инфу о том, какой файл от какого произошел и все такое, но сами файлы сохранятся - мне потом только пересоздать эту бэдэшку надо. А вот если из за нее у меня ядро init не найдет - будет куда как хреновей... Если тебя производительность волнует - ну дык row partition уже давно как используються. Там, где надо... :-)))))))))))))) В фс и так слишком много всякого дерьма понапихали.. Те же права - их просто девать больше некуда, вот и присобачили... А теперь никак на ACL не переползти.. Ладно, скжаем, когда некие вещи под видом фс делаються - в ряде случаев эта модель очень даже удобна, но зачем же все что только можно туда грести ??? Нужна бд - так делай бд, а фс то чего потрошить ??????

2LamerOk: ну для начала посмотри с чего начинались FS... Это были некие liteBD из-за ограниченности ресурсов тогдашних машин...:) Это так, из истории...
А уж раз пошла такая пъянка - тебе не кажется вся эта концепция FS слегка надуманной и лишней? Не проще ли было иметь "плоское" хранилище объектов, единое поле памяти иначе говоря, где ОЗУ выступает как еще один уровень кеша? Никаких тебе open/close file... Нафига эта лишняя сущьность? Если думаешь что это все бред и фантастика, то почитай об AS/400...

"Не проще ли было иметь "плоское" хранилище объектов, единое поле памяти"
Ну только тогда не называйте его FS :-)))))))))) Ведь там же нет файлов :-))))))))

2LamerOk: дело в том что чтоб перейти к использованию такого хранилища объектов (а это имхо идеал к которому надо стремиться) надо отказаться от очень многих принципов построения современных ОС... Смотри - это означает не только отказ от FS в современном виде... Это и отказ от виртуальной памяти в ее современном виде например... Даже от современного, всем привычного гуя, точнее - пользовательского междумордия...:) С другой стороны возможностей FS образца начала 80х (ext2/3, ufs) в современном ОО-мире уже не хватает. Потоки данных в FS это достаточно небольшое усложнене, проще чем в свое время было введение древовидной структуры каталогов...:) А дает это возможность приспосабливать FS к своим потребностям с минимальными затратами времени, сил и ресурсов и при этом - не просто кардинально не менять структуру FS, а вообще ее не трогать...
Не нравятся тебе к примеру ACL - изменил формат потока их содержащие и модифицировал соответствующую либу... ну не либу конечно... в терминах микрокернельных ОС это будет "сервер" - что-то среднее между демоном, модулем ядра и плагином к RaiserFS...:) Не знаю как это назвать в терминах plain kernel...:)

А вот Web прекрасно живет и будет жить на обычной ``деревянной'' структуре (я не имею в виду модель данных XML). И уровень ``select from'' обеспечивается другим.

Эту песню можно и безопасно играть вне ядра. Я думаю сначала любые трюки надо откатать в userspace и только потом можно ставить вопрос об эволюции ФС в мейнстрим ОСах.

Алексей