Главное - не женись. Чисто от греха подальше =).

>...А чего бы еще добавить?

Как чего...супругу по имени Нина,естессно

Посолить и на огонь. Группы для файла, описание и теги - это, канешна, правильно, но это примерно как пацаны с раёна обсуждают десятку: "Спойлера должны быть и подгузники спарцо".

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

Прикольно > Контрольные суммы: crc32+md5

Есть у большинства форматов кроме текстовых

> Группы для файла (например: "фото с едой", "фото на кухне"), дабы не возится с каталогизацией и симлинками - все в самих файлах

Exif

> MIME данных, определяемый по libmagic

Нее в FS толкать 3tht party библиотеки не красиво.

ЗЫ: Не женись!

Для всей этой чуши кроме метаданных (распределения блоков, владельца и прав доступа) существуют extended attributes. Хотите - даже иконки туда сохраняйте.

> Чего должна содержать Ъ файловая система?

Файловая система должна держать структуру каталогов (всю) в оперативке. Мне пох на постоянно занятые 50-100-200 мегов, я хочу мгновенный поиск по диску без коcтылей типа locate.

Ещё хочу мгновенное удаление каталога. Поставил на каталог крыжик "удалено", всё что было внутри ни при поиске, ни ещё как-то не учитывается.

> Файловая система должна

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

Хотите хранить "странные" метаданные? Есть extended attributes.

Хотите "автоудаление"? Есть find -atime -exec

Хотите "восстановление файлов удаленных не далее последних XXX дней"? Есть ln (жесткая ссылка), find -atime и crontab

Хотите хранить контрольные суммы? Tripwire вам в руки.

Кстати вас еще надо полечить для профилактики - вы не задумывались, что контрольную сумму надо считать для каждого блока в файле? Иначе при изменении ОДНОГО БАЙТА в гигабайтном файле вам придется пересчитывать контрольную сумму всего файла?

>3tht

хрена себе у вас английский

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

Ладно, что это zadrot-way, но это просто-напросто не универсально. Переписывать с использованием locate весь софт вы лично будете? Фишка как раз в том, что переделывать кроме ФС не придётся ничего.

> Фишка как раз в том, что переделывать кроме ФС не придётся ничего.

Лечитесь. Реализация в ls опции --tag="мы с пацанами щолкаем семечги" возьмется из libastral, или уже написана?

> Реализация в ls опции --tag="мы с пацанами щолкаем семечги" возьмется из libastral, или уже написана?

Да причём здесь метаданные! Я про структуру каталогов в ОЗУ.

> что переделывать кроме ФС не придётся ничего

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

Реализацию всей этой чуши внешними инструментами можно сделать и использовать на любой из существующих ФС уже сейчас - extended attributes есть почти во всех "родных" ФС, реализацию снапшотов по расписанию можно сделать даже на шелле (делал).

А все эти пожелания про теги и контрольные суммы - напишите свою libSuperFeatures, если она кого-то заинтересует - ее начнут использовать.

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

> Я про структуру каталогов в ОЗУ

find / при старте системы сделайте.

> find / при старте системы сделайте.

Давайте оставим эту тему, так как вы не можете понять, зачем, как, и что я хочу.

Для начала надо почитать как сделаны старые файловые системы, скажем FAT/FAT16/Ext2. Далее читаем как сделаны более современные ФC. И только потом думаем а что не реализовали в других ФС :) А так "хочется это, это и это" реализовать можно, но ведь это все для Виндовс10 требующей 32 процессорный кластер с 2 Тб памяти? :)

А тута http://www.linux.org.ru/view-message.jsp?msgid=2913026&lastmod=1215532637530 смотрел?

З.Ы. Не женись!

> хрена себе у вас английский

Это не английский у нас такой, это пиво с водкой у нас такое

прикрутить реляционную БД к тем ФС что уже есть. в виде дополнительной надстройки. что-то вроде журнала, что отличает ext3 от ext2.

> Давайте оставим эту тему, так как вы не можете понять, зачем, как, и что я хочу

Согласен, оставим. Но скорее потому что мысли д^Wчайника, не знающего ничего о работе файловых систем, как правило не содержат ничего, кроме бреда.

> ничего, кроме бреда

Даша, не хами.

Re^2: Изобретаю файловую систему

>> MIME данных, определяемый по libmagic

> Нее в FS толкать 3tht party библиотеки не красиво.

В unpackfs засунули. Вроде даже работает.

Re^2: Изобретаю файловую систему

> прикрутить реляционную БД к тем ФС что уже есть.

Под fuse уже написали вагон и маленькую тележку ФС, работающих с реляционной базой.

> Давайте оставим эту тему, так как вы не можете понять, зачем, как, и что я хочу.

Для начала вы сами определитесь, что вы хотите :)

разобратся == написать четкое, не содержащее внутренних противоречий, ТЗ, а не список из "хочу ы, типа шоб быо так, будет типа круутааа!! Fap-Fap-Fap!!"

ФС это ещё что. Года три назад один мой друг (сейчас уже виндузятник кое-какой, тогда вообще ламер полный был) увидев как я грузанул с дискеты MenuetOS, на посмотреть, горящими глазами заявил, что года через 2-3 напишет свою ОС... Недавно ему напомнил - он сказал, что пошутил :)

> одну проприетарную фс, название которой тут лучше не произносить.

4.2, ntfs-3g

> Для начала вы сами определитесь, что вы хотите :)

Структура файлов и каталогов находится в ОЗУ. Не кэшируется по мере обращения, а полностью. При записи/изменении пишется в ОЗУ, на диск сбрасывается спустя некоторое время.

> горящими глазами заявил, что года через 2-3 напишет свою ОС

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

>блин, а у меня получилась, даж имхо FAT поддерживала :) эх, сейчас бы столько свободного времени ...

Так вот у кого Билли ДОС купил...

лол, народ. это копипаста с двача. а вы повелись.

> лол, народ. это копипаста с двача. а вы повелись.

Двачую тебе скилл анонизма третей степени

>блин, а у меня получилась, даж имхо FAT поддерживала :) эх, сейчас бы столько свободного времени ...

МакКузик, ты? в общем пруфлинк в студию.

> Структура файлов и каталогов находится в ОЗУ. Не кэшируется по мере обращения, а полностью. При записи/изменении пишется в ОЗУ, на диск сбрасывается спустя некоторое время.

Ололо, идиоты наступают

Описанное тобой относится к политике кеширования и отложенной записи, и не имеет прямого отношения к FS непосредственно. Ядро-патчикам можно такое поведение привить сразу всем поддерживаемым FS: меняем политику на "не вытеснять и не писать до последнего, иметь приоритет невытеснения страниц выше всего что можно", и проходимся при загрузке системы find / -ом по ней, что-бы все попало в кеш.

Или задроты с двача считаю, что проще написать свою фс, потратив несколько лет на сырой прототип, чем написать патчик в несколько десятков строк к ядру?

==== It's our mission to seek our enemies, and kill them one by one

They must be destroyed in time, be sure to teach your new-born son

We must bath in the blood of the vermins, called 2chers, to win

The stuppids are to be executed, for they live in great sin

> Структура файлов и каталогов находится в ОЗУ. Не кэшируется по мере обращения, а полностью.

[dalth@viking ~]$ time find /etc > /dev/null
real 0m1.110s
user 0m0.008s
sys 0m0.020s
[dalth@viking ~]$ time find /etc > /dev/null
real 0m0.018s
user 0m0.004s
sys 0m0.008s
[dalth@viking ~]$ time find /usr/src 2>&1 >/dev/null
real 0m19.947s
user 0m0.088s
sys 0m0.368s
[dalth@viking ~]$ time find /usr/src 2>&1 >/dev/null
real 0m0.211s
user 0m0.064s
sys 0m0.148s
[dalth@viking ~]$ time find /etc 2>&1 >/dev/null
real 0m0.017s
user 0m0.012s
sys 0m0.004s

Теперь отправься в исходники ядра, и читай про VFS и кэш. Ты уж извини, но даже линуксовое ядро умеет думать гораздо лучше чем некоторые посетители этого сайта :-)

Совсем больные на голову могут написать VFScached, который будет открывать на чтение и удерживать открытыми все файлы и каталоги на ФС, так что они из кэша не уйдут.

1. Имя файла
2. Права доступа
3. Отсутствие фрагментации, либо управляемая фрагментация.
4. Самовосстановление
5. Таблица дополнительных данных: колонки и строки, в которые можно записывать различные дополнительные данные. Причём несколько ячеек таблицы надо зарезервировать для стандартных целей.
6. Поддержка сжатия как файлов, так и разделов (есть нечто подобное в виде squashfs, но вроде рид онли)
7. Контрольные суммы (уже в главном сообщении было)
8. Ссылки: жёсткие и символические
9. Быстрые действия типа мгновенной очистки раздела при опредёлнных условиях (ака tmpfs).
10. Кэширование для повышения производительности (фз, наверно даже это не ФС делать должна)
11. Особые возможности: полное удаление (быстро), удаление с перспективой восстановления (медленнее, но зато потом будет меньше криков "б*я!!!!". Да и для самовосстановления ФС будет полезно). Второе много как можно реализовать.
12. Распределение быстродействия: возможность задания приоритета для того, чтобы одни файлы открывались быстрее за счёт более медленной работы с другими файлами.
13. GPL v3


Пока что всё.

> Совсем больные на голову могут написать VFScached, который будет открывать на чтение и удерживать открытыми все файлы и каталоги на ФС, так что они из кэша не уйдут.

Кстаааати... А это мысль. Если правильно подойти к реализации, такой демон можно будет использовать для undelete файлов если не было перезагрузки. Кидаем ему через сокет команду, и он записывает файл в указанное место.

Хотя имхо через одно место - правильнее создавать хардлинки на файлы.

> проходимся при загрузке системы find /

Это же идиотизм! Неужели так трудно в это въехать?

Смысл в том, чтобы для вышеописанного достаточно было один раз при загрузке считать в память подряд N секторов в начале диска.

Ещё тоже идиотизм, который меня просто добивает. Интересно, какой дегенерат придумал каждый раз заново делать начальную загрузку путём последовательного считывания с диска и выполнения тех или иных программ? Есть же очевидное решение, проще, быстрее и более гибкое чем хибернейт.

> 3. Отсутствие фрагментации, либо управляемая фрагментация.

Любая ФС при наличии достаточного свободного пространства

> 4. Самовосстановление

И астральное кэширование. Не бывает восстановления без избыточности.

> 5. Таблица дополнительных данных

extended attributes. Например, ACL - как раз таблица.

> 6. Поддержка сжатия как файлов, так и разделов

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

> 7. Контрольные суммы (уже в главном сообщении было)

extended attributes

> Быстрые действия типа мгновенной очистки раздела при опредёлнных условиях

umount, mkfs

> Кэширование для повышения производительности

Давно все сделано на очень высоком уровне

> Особые возможности: полное удаление (быстро), удаление с перспективой восстановления

unlink / link+unlink + задание в кронтабе, реализуется через библиотеку в юзерспейсе

> Распределение быстродействия: возможность задания приоритета для того, чтобы одни файлы открывались быстрее за счёт более медленной работы с другими файлами.

Не путайте _файлы_ и _задачи_. Для задач уже частично реализован QoS на вводе-выводе. Вне драйверов файловых систем.

> Пока что всё.

И как видно, в новых ФС необходимости нет.

> Смысл в том, чтобы для вышеописанного достаточно было один раз при загрузке считать в память подряд N секторов в начале диска.

А с какого фига вы решили, что все метаданные лежат в начале файловой системы? Есть например HPFS (слышали про такую?) где метаданные лежат на середине раздела. Кроме того, даже в соверменных ФС метаданные раскиданы по всему разделу (оглавление каталоге - это метаданные).

> Интересно, какой дегенерат придумал каждый раз заново делать начальную загрузку путём последовательного считывания с диска и выполнения тех или иных программ

Тот, кто знал слова "взаимные зависимости" и "сериализация". А ты таких слов не знаешь

В топку, тролль!

А говорить про "загрузку" вообще смешно - у меня на рабочей станции аптйам 50 дней, и иметь прозрачную и сверхнадежную систему инициализации гораздо лучше, чем чуть более быструю, но нестабильную и плохоуправляемую. Кроме того, вне зависсимости от системы инициализации, не может работать одновременно процессов больше, чем количество процессоров в жестянке.

> Тот, кто знал слова "взаимные зависимости" и "сериализация".

Так и запишем, "задрот с атрофированным здравым смыслом".

> не может работать одновременно процессов больше, чем количество процессоров в жестянке.

s/одновременно/параллельно/

Вообще, смешной топик. :)

> А говорить про "загрузку" вообще смешно - у меня на рабочей станции аптйам 50 дней

Когда китайский БП дома тебе устроит пожар, я тебе напомню твои "50 дней аптайм".

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

На сервере может быть. Но на ПК - извините.

> Кроме того, вне зависсимости от системы инициализации, не может работать одновременно процессов больше, чем количество процессоров в жестянке.

Упахать всю начальную загрузку в один образ и разворачивать его в память при загрузке. Сразу весь. Те же самые программы, только без необходимости считывать с диска. initrd, но более глобальное.

> А с какого фига вы решили, что все метаданные лежат в начале файловой системы? Есть например HPFS (слышали про такую?) где метаданные лежат на середине раздела.

Знаю, знаю. В журнале каком-то читал лет 10 назад про "уменьшение пробега головок жёсткого диска вдвое при обращении к корневому каталогу" ;)

> Кроме того, даже в соверменных ФС метаданные раскиданы по всему разделу (оглавление каталоге - это метаданные).

Так тоже можно, никто не спорит. А тут платим за мгновенный доступ к каталогам и "стройность" реализации определёнными ограничениями.

> Когда китайский БП дома тебе устроит пожар

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

> Упахать всю начальную загрузку в один образ и разворачивать его в память при загрузке.

Современный "разогретый" линуксовый десктоп сразу после старта удерживает в кэше от 200 до 300 мегабайт данных и библиотек. Если их все запихнуть в "загрузочный образ", это приведет:

1. К невозможности обновить систему за вменяемое время (при обновлении системы необходимо после обновления каждого пакета пересобирать этот образ).

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

3. Некоторые из необходимых для системы демонов присутствуют в памяти постоянно. Это означает, что они удерживают замапленные разделяемые билиотеки "загрузочного образа", и отмонтировать его _нельзя_. Это означает, что после запуска бесполезно будет пропадать около 300 мегабайт оперативнки.

В ваши идеи.

> платим за мгновенный доступ к каталогам

Я уже сказал, как удержать в памяти необходимые тебе объекты - ОТКРОЙ ИХ ДЛЯ ЧТЕНИЯ В ОТДЕЛЬНОМ ПРОЦЕССЕ. Писать новую файловую систему для этого не нужно.

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

> "стройность" реализации

У вас клинический случай. Вы нихрена не понимаете в том, о чем пытаетесь рассуждать.

> уменьшение пробега головок жёсткого диска вдвое при обращении к корневому каталогу

Если бы ты изучал матстат, то был бы в курсе, что такое "матожидание" и какое отношение оно имеет ко ВРЕМЕНИ позционирования головки жесткого диска к нужной в этот момент дорожке жесткого диска. Хотя, какой матстат, какая теория вероятности в вашем ПТУ?

> О господи, ты еще и с азами электротехники и техники безопасности не знаком.

То-то в серверных всегда огнетушители стоят. Не просто баллоны, причём, а целая система с распылителем направленным на стойку с аппаратурой. Идиоты наверное придумывали, куда уж им до лоровских экспертов по всем вопросам...

> К невозможности обновить систему за вменяемое время (при обновлении системы необходимо после обновления каждого пакета пересобирать этот образ).

Скопипастить в один файл сотню бинарников займёт много времени? Могу третий пень подарить в качестве гуманитарной помощи.

> 2. 90% загрузочных программ используют конфигурационные файлы расположенные на ФС, и время их загрузки сравнимо со верменем старта программы, а часто и превосходит его. Перестраивать "загрузочный образ" после каждой правки конфигурационных файлов?

А почему бы и нет? Та же убунта почти всегда не в состоянии загрузиться на другом железе, нежели на том, на котором была установлена. Видюху даже замени nvidia на двугую nvidia - уже обломаешься с Иксами.

> Некоторые из необходимых для системы демонов присутствуют в памяти постоянно. Это означает, что они удерживают замапленные разделяемые билиотеки "загрузочного образа", и отмонтировать его _нельзя_. Это означает, что после запуска бесполезно будет пропадать около 300 мегабайт оперативнки.

Технические надочёты отдельной реализации.

>> проходимся при загрузке системы find /

> Это же идиотизм! Неужели так трудно в это въехать?

> Смысл в том, чтобы для вышеописанного достаточно было один раз при загрузке считать в память подряд N секторов в начале диска.

С технической точки зрения -- разницы ноль, в обоих случаях, один раз, при загрузке, будет считываться в память N секторов где-то из начала диска. Или вы собираетесь совсем все мета-информацию строго в начале хранить? пипец тогда у вас получится нестабильный

> Упахать всю начальную загрузку в один образ и разворачивать его в память при загрузке. Сразу весь. Те же самые программы, только без необходимости считывать с диска. initrd, но более глобальное.

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

Анонимный хам такой анонимный.