Неплохо, но вот кроме объяснения опций монтирования неплохо бы было
затронуть такие вопросы:
1. стратегия физического расположения разделов на диске(ах)

2. влияние физических параметров файловых систем(размер блока, число
блоков/inode, число копий суперблока) и принципы их выбора.

Не хочу обижать автора за неплохую, хотя и краткую статью, но мне
кажется, что стоит обсудить различия в производительности различных
файловых систем, того же LVM и software-RAID(0), например. Кроме того,
недурно провести тюнинг железа хотя бы на уровне hdparm.

ilya

> стратегия физического расположения разделов на диске(ах)

На диске с поддержкой S.M.A.R.T? Да, это очень интересно. Но как ты его узнаешь?

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

Объясняю:
1. Физическое расположение разделов. Если у тебя разделы с /sbin и /var/log (сюда же можно ещё и добавить swap-раздел) будут в разных кусках диска, то одно только время на позиционирование головок винчестера сделает абсолютно никчемными все эти потуги...

2. Насколько я понял, ты предлагаешь держать в одной системы аж целых 3 FS: ext3, reiserfs и xfs (плюс, опять же, swap и какие-нибудь сетевые FS типа SAMBA или NFS). А ты не подумал, сколько памяти будут занимать драйвера? Не лучше ли оставить только reiserfs, swap и ту же SAMBA, но зато освободить память для (хотя бы) дискового кеша?

3. А ты не мерял, сколько времени требуется ядру, чтобы переключиться с использования одной FS на другую? IMHO, тоже не мало.

4. "секурность". Ну это вообще идиотизм. Кто тебе мешает на все приведенные каталоги сделать "правильные" права? Да и (в Slackware, к примеру) там по умолчанию везде стоят права, что юзеры могут только читать/запускать файло. Писать они могу только в /tmp и в $HOME. И нигде на бинарниках stripe bit не стоит. Кстати, забавно вот что: на скрипты stripe bit не действует, а потому даже от "страшных" скриптов, запущенных из-под юзера, системе не будет ровным счетом ничего.

P. S. Ещё хочу отметить, что указанные мной в пп. 1-3 огрехи в производительности сильнее всего скажутся на слабеньких машинах... А 4-му Пню на 3 ГГц частоты с гигабайтом оперативки будет абсолютно паралельно сколько ты в ядро файловых систем накидаешь.

А как в Линаксе отформатировать раздел отличный от ext3 создать то я могу заранее спасибо

2root:

2. ого как! Ну что ж попробуйте откомпилировать ядро со всеми файловыми системами и вообще без них. Если там будет хотябы полмегабайта - я пожму вам руку.

3. да... дядя... да вы делитант... это как вы себе представляете переключение ядра с одно ФС на другую?

4. ой-ой... Это что еще за stripe такой? sticky bit? Вы знаете в линуксе он уже давно не имеет никакого значения. Или SUID? эх... может прочтете зоть одну книжку про unix/linux? Вот так и появляется куча админов-любителей-slackware и ихние дефейснутый сайты...

А вообще статья очень грамотная, хоть и короткая и немногословная.

делитант - это диагноз

А вот такой вопрос

Файловые системы в loop device'ах насколько медленней обычных?

как обычно шлаководы показали себя с лучшей стороны (root) :))

<цитата>Если у тебя разделы с /sbin и /var/log (сюда же можно ещё и добавить swap-раздел) будут в разных кусках диска, то одно только время на позиционирование головок винчестера сделает абсолютно никчемными все эти потуги...</цитата>

Почему же именно /sbin, а не, скажем, /usr/bin или /lib? а вы не забыли, что в линуксе обычно работает неколько процессов и _в_любом_случае_ головки жесткого диска будут постоянно бегать?

<цитата>А ты не мерял, сколько времени требуется ядру, чтобы переключиться с использования одной FS на другую? IMHO, тоже не мало.</цитата>

Это как вы себе представляете? там нет никакого рубильника, который переключает FS.

<цитата> А как в Линаксе отформатировать раздел отличный от ext3 создать то я могу заранее спасибо </цитата>

смотри mkfs Например

mkfs -t reiserfs /dev/hda2

2 R00T (*) (2003-06-01 20:59:25.045169)

>1. Физическое расположение разделов. Если у тебя разделы с /sbin и /var/log (сюда же можно ещё и добавить swap-раздел) будут в разных кусках диска, то одно только время на позиционирование головок винчестера сделает абсолютно никчемными все эти потуги...

ДА!!! Правильно!!!
Кидаем все в один раздел и кладем на многолентий мировой опыт администрации UNIX'ов!!!

> 3. А ты не мерял, сколько времени требуется ядру, чтобы переключиться с использования одной FS на другую? IMHO, тоже не мало.

Без коментариев....

> 4. "секурность". Ну это вообще идиотизм.

Правильно!!!
В жопу секьюрити!!! Нахер она кому-то нужна!!!!
И приклеим бумажку к монитору с ROOT'овым паролем, дабы не забыть ненароком....

P.S. Вы у доктора давно были????

P.P.S. А статейка очень даже ничего, не без огрех конечно, но...
В общем согласен с anonymous (*) (2003-06-01 18:39:40.288056)

При некоторых условиях, loop-устройства могут оказаться "быстрее" обычных - за счет того, что операции над ними попадают в кэш (проверено на практике :-)). Но в "чистом" случае, разница в производительности "сырого" и loop устройства будет примерно такая же, как и разница между чтением например, из /dev/hda1 и чтением файла, лежащего в файловой системе на /dev/hda1 - т.е. все очень сильно зависит от собственно ФС.

статья хорошая. не очень верится про существенную полезность noatime для сквида. если есть ссылка на экспериментальные данные киньте плиз.

Люди, стоит доверять resize_reiserfs? Дистро SuSE 8.2 Нужно удалить один раздел, а один заресайзить (чтобы он его место сожрал), оба на reiserfs, бэкап _всего_ сделать не могу, и вот боюсь дёргаться. help

Прежде всего статья должна называться типа "Изврат ФС для начинающих"...

2R00T (*) (2003-06-01 20:59:25.045169): Ясно, что автор о таком вообще не думал!!! Его Вывод - много это круто!!! А если так, то он забыл про JFS. Для полной ясности можно еще и про fat и ntfs дописать... Им тоже можно пременение найти ;-)

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

Для начала было бы не плоха определить применения использования железа, а потом уже толкать кучу фс. Иначе это просто необъективно aka ИЗВРАТ Это сервер/Какой/Задачи/Нагрузка/Надежность... Это для начала.

Не кажется ли совсем тупо использовать связку XFS-REISERFS ?!?! Всегда считал, что они конкуренты.

А что лучше надежность или скорость(по его логики скорость == raiserfs, надежность == xfs.) Значит опять таки автору забить на надежность ??? И это сервер ? Гы-гы.....

Не факт, что raiserfs делает по скорости xfs (видимо автор про нее ни хер@ не знает.)!!!!!!!!! Про другое даже и говорить не буду...

Далее критиковать статью ИМХО глупо, т.к. сразу бросается в глаза его предвятость: ext3 и reiserfs.

Лично я предпочтения отдаю XFS!!!

fbx

А мне кажется статья больше вредная, чем полезная. Разбитие
разделов и виды фс - сугубо личные религиозные понятия
сисамина. noatime не совсем верно объясняется и пример плохой.
Я, например, в сквиде использую nullfs, и noatime ему до
лампочки. С другой стороны забыта и не описана опция nodiratime.

Далее, разбивка разделов более чем спорная. Я всегда делаю
/boot в составе рутовой партиции, размер которой не превышает
1Гиг. Мне кажется отджельный /boot - лишняя возня и засорение
итак ограниченного количества primary partitions.

/usr у меня так же не выделяется и расположен на рутовой
партиции. Я считаю, что /usr не должен сильно изменяться после
установки дистрибутива. Это базовая часть системы. Ну и
естественно, что /usr/share/doc на отдельном разделе - это
такое же излишество и неоправданное размножение сущностей.
Если в сети много однотипных машин, то весь /usr иммеет смысл
монтировать по nfs.

Описание /var/log не только кривое, но и вредное. "При сбоях
или DoS атаках размер журналов может резко увеличиваться,
тем самым переполняя этот раздел." - это чушь. Админ должен
планировать размер логов и не допускать переполнения
програмно. В случае переполнения фс сервисы согуцт прекратить
работу ожидая диск. Так что ограничение объема раздела для
логов - это не решение проблемы.

"На серверной машине, скорее всего, имеет смысл ставить на этот раздел флаг noexec" - вообще полная чушь. Юзер может и
должен иметь ~/bin.

2FBX
Насколько я помню, ReiserFS быстрее при работе с мелкими файлами,
особенно когда их очень много, а XFS лучше при работе с большими файлами
(скорость блочного чтения выше). Ну и плюс ACL (нужно на самом деле
не только для Windows)
Так что все вполне логично:
/usr на reiserFS (там куча мелких утилиток, да и /usr/include - большая
куча мелких файлов)
/var/log на xfs (логи достаточно большие и их не так уж и много)

Не совсем понятен выбор ext3 для /var/tmp. На /var/spool/mail тоже по идее
лучше ставить reiser - письма как правило небольшие, но их много
(вот только не помню, квоты там доделали или нет).

Мне вот интересно, есть-ли какая-нибудь статья, опубликование ссылки на которую тут не наводит волны кидания какашек?

злобный ико варчун

/boot и /юзер в рутовой гигабайтной партиции - КРУТО и ПРАВИЛЬНО. При авариях _ВСЕ_ должно наебнуться _ОДНОВРЕМЕННО_ и _ СРАЗУ_ ! Такая идеолгия полностью исключает ковыряние с fsck и ручное восстановление файлов. Спасибо за положительный опыт. Сочуствую по поводу ограниченного числа праймэри партишинов - их действительно надо беречь. Из небольшого опыта работы с серверами - все рекламные заявления по поводу журнальных ФС - пиздешь. Единственная нормальная ФС - ext2.

> Такая идеолгия полностью исключает ковыряние с fsck и ручное восстановление файлов. Спасибо за положительный опыт.

Я не понял, это сарказм или как? На всякий случай упомяну, что
на моих серверах везде стоит raid0.

s/raid0/raid1/

> есть-ли какая-нибудь статья, опубликование ссылки на которую тут не наводит волны кидания какашек?

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

Статья хорошая, но _очень_ поверхностная. Больше напоминает заметки на полях ;).

Предложение автору:
1). Добавить теории (почему atime положительно влияет на скорость squid'а, например).
2). Добавить введение, в котором написать хотя бы несколько сценариев "если ..., то ...". Пример: "Если на разделе предполагается хранить кучу мелких файлов, которые часто создаются и удаляются, а также часто читаются и пишутся (например для /tmp), то ...".
3). Добавить примеры типового разбиения ("...а на домашней машине диск предлагается бить так: ...").
4). Больше ссылок на источники информации и другие ресурсы.
5). Почему для /home не предлагается устанавливать флаг nodev?!?! ;)

Скорее эта статья находится в /usr/doc/Linux-HOWTO/Filesystems-HOWTO с поправкой, что она может немного устареть ... да у меня от 20 августа 2000 года 8-).

А раздел для squid чаще всего рекомендуют ставить на reiserfs с noatime, nodiratime, notail.

А вот зачем отрывать /boot, /usr от / ??? Вы так часто пишете в / или /usr или /boot на сервере? Как правило видел и сам так делаю - выделяют в отдельный раздел /var или /var/log, иногда еще /tmp, если многопользовательская, то и /home. При установке спец. приложений можно еще например /opt/postgresql и /opt/postgresql/data (каталог с БД), и /opt/postgresql/backup (резервные копии БД соответственно), тут можно postgresql заменить на samba например ... ext3 хорошая журналируемая fs, хотя сбои бывают везде. Вот лучше скажите - стоит ли для ext3 отключать fsck на рабочей станции? А на сервере, желательно с аргументацией...

С уважением, Олег.

Да по поводу переключения fs: если долго не обращаться к разделу, например XFS, то при открытии каталога куда смонтирована fs происходят тормоза ... секунд 3-5, даже на 2xP3-933 с 512Mb RAM :))) и HW RAID-1 ... это так для справки ... особенно если к разделу не обращались уже месяц, а вот если все разделы ext3, то открытие происходит быстро (1-2 секунды) - проверено, это факт. Повод задуматься, что возможно в чем то R00T был прав...

2 saper (*) (2003-06-02 02:15:13.841318)

/boot например для того чтобы иметь его под ext2 (потому как понимается многими тулзнями, может панадобиться при recover'е), чтобы унести его в первые 1024 цилиндра (наверное сейчас уже не актуально) ну и чтобы можно было его держать отмаунченным при нормальной работе (дабы не навернулся).

/usr - например для того чтобы держать его read-only и перемоучивать в read-write только на время апдейтов. "/" вам скорее всего неудастся сделать read-only без большого напильника потому как на большинстве дистров кое что что пишется в /etc во время загрузки (например /etc/mtab, /etc/motd) и сам /etc отделять противопоказано.

/home вообще надо отрывать обязательно (и беречь как зеницу ока) потому что там лежат личные файлы пользователей которые по понятным причинам не восстановливаются переустановкой системы.

/tmp и /var/tmp - скорее для оптимизации.

/var/spool/mail, /var/spool/news, /var/cache/squid ... - чтобы вышедший из под контроля демон не положил систему.

ну и так далее.

А вообще - чем больше разделов вы имеете, тем больше у вас свобода тюнинга системы.

Hope it helps.

> /boot например для того чтобы иметь его под ext2 (

Дык он и так может быть под ext2, даже если в составе рутовой
партиции. Еще раз: делается рутовая партиция размером 1Гиг под
ext2. В ее составе /boot и /usr. fsck для 1Гига делается очень
быстро, так что журнал там ни к чему.

> /usr - например для того чтобы держать его read-only

Если паранойя не лечится, то уж идти до конца и делать
read-only всю рутовую партицию. mtab лечится заменой его на
симлинк в /proc/mounts.

> /var/spool/mail, /var/spool/news, /var/cache/squid ... - чтобы вышедший из под контроля демон не положил систему.

Хм, сомнительный совет. Я бы посоветовал заменять выходящие
из-под контроля демоны на послушные. /var/spool/mail - это устаревшее и небезопасное дерьмо. Юзайте qmail. Ньюсы - тоже
атавизм. Юзайте списки рассылки. Сквид в конфиге имеет
ограничитель на дисковое пространство. Все доводы гнилые.

> А вообще - чем больше разделов вы имеете, тем больше у вас свобода тюнинга системы.

Враньё. Деление на разделы хорошо до разумных пределов. Оно
не беспредельно, и вызвано скорее соображениями безопасности,
а не скорости доступа. Наоборот, чем крупнее разделы, тем
больше свободы маневра.

Автору статьи учиться, учиться и учиться как завещал великий гуру ;)

1Гиг на сбойном диске может чекаться 2-3 часа. Может кому это и быстро

у меня вообще все на одном партишине, да и тот ext2. так имхо прикольней.

>Дык он и так может быть под ext2, даже если в составе рутовой партиции.

неудобно. у меня /boot на 100Mb и стоит в noauto, хряню там около 10 ядер и bash, fdisk, parted и пр....

>/var/spool/mail - это устаревшее и небезопасное дерьмо. Юзайте qmail.

тогда делать нужно /var/qmail

>Если паранойя не лечится, то уж идти до конца и делать read-only всю рутовую партицию.

ну зачем так грубо ? в /bin, /sbin, /etc и в /lib совсем немного барахла, это и забекапить можно.

2 anonymous (*) (2003-06-02 04:14:31.137259)

>а также например /etc Если паранойя не лечится, то уж идти до конца и делать read-only всю рутовую партицию. mtab лечится заменой его на
симлинк в /proc/mounts.

ну во первых это не равнозначная замена, а во вторых как быть например с /etc/resolve.conf ? да, я знаю что NS сервера меняются ОЧЕНЬ редко.... Но в моей практике такое было..... И не у всех же static IP, некоторые на DHCP сидят

> Хм, сомнительный совет. Я бы посоветовал заменять выходящие
из-под контроля демоны на послушные. /var/spool/mail - это устаревшее и небезопасное дерьмо. Юзайте qmail. Ньюсы - тоже
атавизм. Юзайте списки рассылки. Сквид в конфиге имеет
ограничитель на дисковое пространство. Все доводы гнилые.

И вы на 100 процентов уверены что все ваши демоны "послушные" ????
Вы чсастливый человек.....

>> А вообще - чем больше разделов вы имеете, тем больше у вас свобода тюнинга системы.

>Враньё. Деление на разделы хорошо до разумных пределов. Оно
не беспредельно, и вызвано скорее соображениями безопасности,
а не скорости доступа. Наоборот, чем крупнее разделы, тем
больше свободы маневра.

Ну во первых "тюнинг" включает в себя тюнинг по security, а во вторых, если следовать вашей логике - то _один_ раздел - идеальный вариант.

> mtab лечится заменой его на симлинк в /proc/mounts.
а точно? ведь сдержания у них разные. да и какие программы используют /etc/mtab
и только ли /etc/mtab изменяется?

Замена /etc/mtab cимлинком на /proc/mounts приводит к облому при последующей попытке включения квот.

Гы, опять вылез чудило ROOT с гениальными познаниями в области ЭВМ :) На сей раз полосатые биты изобрел, наверное диск ему цветной втюхали.

О производительности.

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

Однако в его словах есть доля истины. Хотя бы потому, что XFS и Reiser - довольно сложные системы с большими драйверами. Посему, при попытке доступиться к файлу "/[on-extX]/[on-xfs]/[on-reizer]" (к примеру) будет задействовано намного бОльше кода и данных, чем в тривиальном [/on-ext3]/[on-ext3]/[on-ext3]. В результате чего процессорный кеш (разный) будет использоваться не так эффективно. Что в какой-то степени повлияет на скорость исполнения пользовательских программ.

Статья начального уровня. И для этого уровня достаточно грамотная. Не понимаю чего некоторые как с цепи сорвались.

>>>>>>> Сквид в конфиге имеет ограничитель на дисковое пространство.

a na log fayl toje ogranichitel est ??? on bistro virastet (menee chem za paru chasov) esli bombit squid zaprosami - eto uje prohodili.

А почему простите ньюсы атавизм ? Некоторые даже натив фидо до сих пор юзают !

>>Люди, стоит доверять resize_reiserfs? Дистро SuSE 8.2 Нужно удалить >>один раздел, а один заресайзить (чтобы он его место сожрал), оба на >>reiserfs, бэкап _всего_ сделать не могу, и вот боюсь дёргаться. help

Я бы не рискнул. Попробуй parted+libreiserfs.

Ну и не поленись, сделай сначала бекап, а пеерд ресайзом запусти fsck --check. Иначе resize незакончится нормально если например встретит ноду с непонятным уровнем.

P.S. У reiser4 будет правильный ресайз -- онлайн ресайз через журнал.

Подскажите мне, как устанавливать полосато-нашивочно-шевронный бит (stripe-bit), а?

Да никакай производительность не окупет всеготого гемора который надо проделать для разбивки этих дисков

> a na log fayl toje ogranichitel est ???

Конечно. Лог переадрессуется в stdout и ловится специальной программой, которая делает авторотацию.

А по-моему нормальная статья. И каждый вибирает ФС и разбиение ХДД для себя сам по принципу: как хочу, так и дро... :) Тока есесно после сбоев и дро.... по тому же принципу. Лично сам делаю так:

отдельно /, /home, /usr, /var, /tmp ну и swap. Вот в принципе и все. Вряд-ли есть смысл делать отдельный раздел для /boot. Легче с дискетки грузанутся. Главное про backup не забывать.:)

2 anonymous (*) (2003-06-02 15:24:07.578913)

>Да никакай производительность не окупет всеготого гемора который надо проделать для разбивки этих дисков

Окупит, окупит ,) К тому же мы говорим не только о производительности, но и о стабильности и maintainability системы. А единственный геморрой - правильно оценить размер разделов...

Чем-то старознакомым от Микрософта веет от этой статьи ИМХО. "Делайте ВОТ ТАК! А "зачем, почему" не вашего ума дело..." Давайте попробуем определиться - чего в системе покатоложно происходит и что нам дают определенные ФС. Позволю себе изложить собственное видение вопроса.

Сначала о записи данных:

При загрузке системы совершенно однозначно происходит запись в /etc/mtab (монтирование) и /etc/ld.so.cache (вызов ldconfig). Может происходить обновление /lib/modules/2.x.x/modules.dep (вызов depmod -a).

При монтировании разделов пользователем происходит запись в /etc/mtab.

При смене пароля меняется /etc/shadow (тоже от пользователя).

При использовании pppd происходит запись в /etc/ppp/resolv.conf (не помню точно, давно не юзал).

Наконец что-то писать куда угодно может суперпользователь. (появление в /dev сетевых устройств тоже на него спишем :)

В остальном при обычной работе системы запись происходит в /home/* /tmp/* /var/*.

Запись времени доступа на чтение к файлам:

При установленной опции atime в inode происходит запись access time при каждом чтении. Оно нам всегда надо? Я склонен использовать noatime для публично доступных данных (я бы предложил высказаться по этому вопросу).

Из этого я делаю такой простой вывод, что вынесение /home /tmp /var в отдельные ФС и использование noatime резко снижает вероятность сбоев в корневой ФС (более того, резко снижает необходимость журнала - скорее нужна опция sync при монтировании).

Возможность загрузчика погрузить ядро:

1. Расположение ядра и загрузчика на диске

2. Несовместимость загрузчиков с упаковкой концов файлов для reiserfs.

Эти две причины (ничего не знаю про XFS,JFS) чаще всего и заставляют выделять /boot в отдельный раздел. При обычной работе в него тоже не пишется - можно не использовать журнал и добавить noatime.

Перейдем к используемым типам ФС:

EXT2:

Журнал отсутствует, опция sync точно работает (для остальных типов ФС скорее НЕ работает, может быть кто-то уточнит). Структура каталогов - линейная (неудобна для каталогов с большим количеством файлов - долго искать). Права традиционные "владелец-группа-остальные".

EXT3:

То же, что предыдущая, но журнал и опция sync с точностью до наоборот :)

Reiserfs:

Журнал, каталоги-сбалансированное дерево, экономия места за счет совместного хранения концов файлов и вообще много вкусного, права вроде традиционные, есть одна непонятка: насколько система устойчива к появлению сбойных блоков на диске?

Предлагаю дополнить|поправить где неправ :)

Irsi как всегда в пролёте

http://www.linux.org.ru/view-message.jsp?msgid=322172&scroll=section&...

В общем, про stripe bit... Во время написания того дела я больше думал про опции компилятора GCC-3.2.2. :-) Вот и написал stripe bit вместо suid bit. :-)
Зато как все всполошились-то... Просто уму не постижимо, как анонимусы любят цепляться к словам, но просто не могут высказать никаких мнений по существу вопроса.

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

Про скорость переключения между файловыми системами вполне четко высказался DonkeyHot (*) (2003-06-02 11:30:56.23187) - я именно это и имел в виду.

2 R00T (*) (2003-06-02 18:12:36.78852)

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

Так все таки выносим spool & cache на отдельные партиции ???

>Доступа к машинам (я имею в виду telnet) у пользователей нет - соответственно, и порушить они ничего не могут.

Вот это спорно... Живые юзера - нет, а вот демон запущенный не из под рута - вполне (если дополнительно ничего не предпринять).

> Так зачем же извращаться-то? Может, правду кто-то сказал, что это паранойей попахивает?

То, что у вас нет паранои, еще не значит что за вами никто не следит :))

> Про скорость переключения между файловыми системами вполне четко высказался DonkeyHot (*) (2003-06-02 11:30:56.23187) - я именно это и имел в виду.

БУЛЩИТ. по многим причинам.

Даже если предположить что пробуксовка связанная с вытеснением кода fs из кеша процессора измерима то, учитывая что с 99% вероятностью обращение /on-extN/on-xfs/on-reiserfs выльется в одно обращение к reiserfs, о потенциальной пробуксовке можно говорить только если к разделу on-reiserfs обращаются раз в пятилетку. А о патерне user-space -> driver extN -> user-space -> driver reiserfs я вообще молчу, потому что наличие user-space части делает наличие кода fs driver'а в кеше процессора вообще непредсказуемым (я к тому что патерн user-space - driver extN -> user-space -> driver extN ничем не лучше).

А теперь подумайте на сколько ПОРЯДКОВ различаются времена доступа к памяти и диску! Игры с процессорным кешем становятся просто смешными...