Ну, как только reiserfs «сгниет», или же появится реально лучшая файловая система - перейду на нее. А пока что не вижу смысла изменять reiserfs'у. А нужно мне немного (как я уже говорил выше): расширенные атрибуты (по сути - встроенная база данных, где можно было бы для каждого файла назначать отдельные права каждому пользователю и каждой группе; скрывать файлы/директории от конкретных пользователей/групп; создавать реально immutable-файлы и т.д., и т.п.), встроенная возможность сжатия (в основном для книжек) и встроенная возможность шифрования.
In Linux, the ext2, ext3, ext4, JFS, ReiserFS, XFS, Btrfs and OCFS2 1.6 filesystems support extended attributes (abbreviated xattr) when enabled in the kernel configuration.
Вот доков мало, приходится по крупицам собирать. Вопрос, имхо, нужно бы разделить на 2. Есть слой адаптации - VFS. Это некий универсальный интерфейс между ядром Linux и кодом файловой системы.
Т.е. нужно искать инфу по VFS. - Тут есть книжка «Разработка ядра Линукс», автор Роберт Лав. Находил еще пару статей, в том числе и на русском. Собственно, тут ничего особенно сложного нет, нужно регистрировать свою фс в ядре, потом заполнять зубодробильные структуры размером на несколько рулонов обоев. В частности, ставить указатели на функции, которые будут дергаться в тех или иных ситуациях, например, при создании файла. Вот по статьям приходится по крохам собирать объяснения тех или иных полей в структурах VFS.
Ну а по второй части вопроса можно написать докторскую диссертацию. Собственнно, наверно и пишут :-) Для начала - Таненбаум, «Современные операционные системы». Ну а дальше тоже по статьям, по методом. Здесь уже простор для воображения и нужны серьезные знания в математике. В частности, читал статьи Эдуарда Шишкина. Он кстати, в пух и прах критикует btrfs и ext4. В общем, тут простор для дизайна. К сожалению, мне потребовался еще и ускоренный курс дискретной математики, чтобы хотя бы читать и разбираться со статьями по теории фс. Дерзайте :-)
-------------
В дополнение ко всему выше сказанному, хочется также добавить, что нужен будет еще и некоторый опыт в программировании ядра, или хотя бы готовность этот опыт получать. Не ждите, что у вас все заработает с первого раза, так как есть куча подводных камней. Умение обходить эти камни, боюсь, достигается только наработкой, только опытом. Тоже приходится собирать по крупицам.
Например, из самого такого огромного кораллового рифа - msleep(). Коварная функция. Отправляет к-трид (kernel-трид, поток исполнения в ядре, ядро тоже многозадачное :-) ) в сон, присваивает потоку свойство, что его можно перекрыть, т.е. остановить и переключиться на другой поток. НЕЛЬЗЯ вызывать ее из контекста прерывания! Потому что возвращаться будет некуда. Так же она несовместима со спин-блокировками. Тут верно и обратное, если у вас поток может уйти в сон, то НЕЛЬЗЯ использовать спин-блокировки. Казалось бы проблема исчерпана, но! многие функции ядра отправляют к-трид в сон. Причем это не всегда документировано. Например, копирование данных из/в userspace стопроцентно положит ваш поток спать, ядро займется пока более интересными вещами и разбудит ваш поток, когда копирование закончится.
Хех... ладно, мне конечно хочется поделиться своим опытом, как я себе граблями по лбу долбил... но всего не передашь. В общем, такие вот пироги с котятами.... :-)
Я не про это. Выше же я расшифровал, что мне нужно: чтобы каждому файлу можно было задать список пользователь-права + группа-права, ну и т.п.
Т.е., например, имеем файл atext1.tex. Мы хотим дать возможность пользователю x возможность полного владения файлом (в т.ч. возможность удаления), пользователям a,b и c, а также всем пользователям из группы GA - возможность редактирования без удаления, пользователям d,e и f, а также всем пользователям из групп GB и GC - возможность чтения без редактирования, пользователям g и h, а также всем пользователям из групп GD, GE, GF и GG - возможность видеть, что этот файл есть в директории, всем остальным пользователям - даже не видеть, что он есть.
Нет таких, увы...
А, да: про версионирование еще забыл. Т.е. еще и mercurial встроить в ФС ☺
No mainstream Linux file system supports versioning, but a number of experimental/research and lesser-known solutions do, namely:
ext3cow
NILFS - A log-structured file system supporting versioning of the entire file system and continuous snapshotting.
Tux3 - As of 2010-11-09 the last code update was 15 months ago. [1] and the last news update was 2008-11-25. [2]
btrfs[dubious – discuss]
Next3
А, понял. Да: для файла с атрибутом «версионирование» все изменяемые (а также удаляемые) блоки не удалять, а лишь вносить соответствующую запись в дерево версий.
Это позволило бы еще и организовать параллельную работу нескольких человек с одним и тем же файлом (со сверкой версий в дальнейшем).
Будет польза, если вы вдруг возьмете и напишете адекватную альтернативу FAT32 (exFAT), которую можно бы было использовать во встроенных системах, телевизорах, холодильниках и унитазах, в которой бы отключались права, и которая бы была проста и поддерживаема всем, на шо можна подать электричество. Тогда ваше имя было бы вписано в историю.
А со всякими онанизьмами бесконечными типа бтрфс, искфс, рейсерфс и прочими зфсами, задроты разберутся и без вас. Ибо пишут они это все вовсе не для людей, а мастурбации ради.
А вот сделать по-человечески. А то глупо такие дурацкие ограничения вводить. Я вообще не понимаю: почему я не имею права создать дерево директорий с вложенностью эдак в 1000 подуровней, назвав каждую родительскую директорию эдак 1000 символов…
Вы, батенька в степи широкой живете наверное, где людей совсем нет? Ну как я дам этот диск кому-то посмотреть-попользоваться? Или проблемы индейцев шерифа не волнуют? Так тогда и проблемы шерифа индейцев рано или поздно перестанут волновать.
Хех... ладно, мне конечно хочется поделиться своим опытом, как я себе граблями по лбу долбил... но всего не передашь. В общем, такие вот пироги с котятами.... :-)
Eddy_Em
Она весело сыплется при отключении питания.
Делитесь знаниями в блоге, будет интересно изучить.
В любом деле есть те или иные допущения. Например, при оцифровке сигнала, цифровая кривая не полностью повторяет аналоговую. Такие же допущения есть и в программировании. Есть некий компромисс между фишками и быстродействием, требованием к ресурсам. Извините, если у вас ядро будет жутко тупить при записи в файл и жрать ресурсов едва ли не больше, чем вся среда пользователя, то скорее всего ничего хоошего из этого не выйдет.