Форум на Исходниках.RU

ФСы -- ext2, ext3, reiser.

the_Shadow — Fri, 26 Mar 2004 09:56:46 +0000

the_Shadow: 2 DEil.
Выходит -- хорошо? А как входит? :-DDD
Да, кстати, насколько я понял, ты Слаке решил с Фряхой изменить или я промазал? ;-D

ФСы -- ext2, ext3, reiser.

DEiL — Thu, 25 Mar 2004 18:29:44 +0000

DEiL: 2the_Shadow -> знайемс, пробовали :-)
у меня на втором компутере кластер в 32кб на ФАТ32 имеется. и ничего, живём.. блин.. =)

ФСы -- ext2, ext3, reiser.

the_Shadow — Thu, 25 Mar 2004 09:17:17 +0000

the_Shadow: Ну, если тачка достаточно мощная и каких-то особонаворочанных в смысле вычислений задач нет, да и винты если здоровые, то можно ставить что угодно. :-D В моих условиях -- PII 350, 128, 4Gb (ещё 2 под M$, итого 6), лучше не рисковать. :-D

ФСы -- ext2, ext3, reiser.

SergeS — Wed, 24 Mar 2004 20:54:00 +0000

SergeS: the_Shadow,
Ну - я ж ставил с дистримбом , себе ради интереса потом прицепил Реизер

ФСы -- ext2, ext3, reiser.

the_Shadow — Wed, 24 Mar 2004 13:35:42 +0000

the_Shadow:

Цитата DEiL @ 24.03.04, 02:46

вообще, для декстоп-юзеров (да и наверное уже не только для них) подобная тема плавно переходит в разряд "зачем мне реализовывать quicksort, если мой p4-3.2EE может перемолоть милионный массив bubble sort'ом за 1мс?" ..

Угу... Угу... Угу... :-)
А теперь прикола ради создай 1 файл на 100 байт. А теперь прикинь -- 100 байт, да? А размер блока минимальный -- 4096 байт, так? И... какова, интересно, потаённая суть и сермяжная правда столь экономного расхода дискового пространства? А что будет, если таких файлецов будет тысяч несколько? :-D

Дальше. А вот представь теперь -- создаёшь ты такие вот мелкие tmp-файлы... По окончании "процесса" ты их удаляешь. Вот теперь вопрос -- а зачем все эти муки ФС по поводу упорядочения структур данных именно в ФС (которые свершают все журналирующие ФС)?

Я не спорю с тем, что новое -- хорошо и прекрасно, но вопрос его внедрения должен быть хорошенько обдуман. У меня слишком мало времени на эксперименты... :-(

Добавлено в 24.03.04, 13:38:

Цитата SergeS @ 23.03.04, 21:54

.... у меня стоит reiserfs у него ext3 ....

Я бы даже ext3 и не ставил бы... Остановился бы (да, собственно, так и сделал) на ext2... :-)

ФСы -- ext2, ext3, reiser.

CKulT — Tue, 23 Mar 2004 22:52:50 +0000

CKulT: скорость записи - ~17 МБ/сек с веника FAT32 на веник ResierFS, вплоть до остатка свободного места 50 Мб на райзере :)

ФСы -- ext2, ext3, reiser.

DEiL — Tue, 23 Mar 2004 21:46:31 +0000

DEiL: вообще, для декстоп-юзеров (да и наверное уже не только для них) подобная тема плавно переходит в разряд "зачем мне реализовывать quicksort, если мой p4-3.2EE может перемолоть милионный массив bubble sort'ом за 1мс?" ..

Добавлено в 23.03.04, 21:47:
-)

но читать было интересно! :)

ФСы -- ext2, ext3, reiser.

SergeS — Tue, 23 Mar 2004 18:58:50 +0000

SergeS: the_Shadow,
Скорость записи ... хм - погоняю .... занимает - не мерял %) ( при моём диске оно меня не так интересуент )

ФСы -- ext2, ext3, reiser.

the_Shadow — Tue, 23 Mar 2004 17:25:07 +0000

the_Shadow: Ха! Читает -- быстрее. Не спорю, а вот пишет файлы и сколько всё это хозяйство место занимает (насколько полно использует винт) -- вопрос. :D

ФСы -- ext2, ext3, reiser.

SergeS — Tue, 23 Mar 2004 16:54:54 +0000

SergeS: У меня дома два одинковых компа - мой и отца ( купили в одно время туже модель ) - у меня стоит reiserfs у него ext3 .... и сто - у меня комп летает в 1.5 раза быстрее

ФСы -- ext2, ext3, reiser.

grustnoe — Tue, 23 Mar 2004 15:42:05 +0000

grustnoe: вот как у Vit-а сервер начнет нормально работать - поверим в преимущество ext2 :)

ФСы -- ext2, ext3, reiser.

the_Shadow — Tue, 23 Mar 2004 14:17:58 +0000

the_Shadow: WARNING! WARNING! WARNING!
Господа, всё нижесказанное -- моё IMHO и не более.

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

Суть проблемы была в том, что при работе/тестировании открывалось множество
файлов, записывалась туда небольшая порция данных и файл закрывался. Причем,
работа строилась на основе smbfs. Подробнее см. тему ->

Я рискую утверждать что в ряде случаев (особенно это касается множества мелких
файлов и "серверных" систем) все-таки лучше использовать более старую систему
ext2fs, нежели более новые ext3fs и reiserfs. Лучше
использовать именно в смысле скорости исполнения операций записи, а
не в смысле утверждения что лучше потому, что ext2fs -- отстой или *fs --
рулёз фарэва, все остальное -- отстой. Подобного рода аргументация не проходит,
точнее, не в данном случае и не в данном разделе Форума. Извините... Задолбалллло.
Я не великой спец в области ФС, но с кое-какими выводами из своих "развлечений"
познакомить могу. Оговорюсь сразу -- я использую наиболее старую ФС -- ext2.

В данной теме я намерен:
1. Разобраться с тем, а как вообще вся эта крень работает. Это я про ФС.
2. Обосновать ранее приведенное высказывание.
3. Если я не прав, то увидеть аргументированное обоснование своей неправоты.
4. Я не претендую на роль "истины в последней инстанции" или ещё какого варианта
"супербизона".

1. "Печка".
Как вообще строится ФС в Linux? Я говорил это раньше и повторю это сейчас. В Linux выстроена
уникальная система по обработке файлов. Т.е. основа любой ФС в Linux -- Virtual File
System, в задачи которой входит обработка данных именно на уровне ядра. Т.е. безразлично
какой конкретно ФС мы пользуемся на данной машине и в данный момент времени. Для ядра
любая подмонтированная ФС суть точно такая же как и любая другая подмонтированная ФС.

Кстати сказать. Не помню до какой версии, но раньше VFS строилась на базе ext2fs, которая
была "несущей конструкцией" для неё (root filesystem). Сейчас, я подчеркиваю, любая
ФС строится на базе VFS, в т.ч. и ext2fs.

Итак, любая ФС строится на базе единых строительных блоков (базовых понятий, если угодно).

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

См. /include/linux/fs.h. Это суперблок VFS! Учтите это! Суперблоки для конкретных
ФС разложены по каталогам соотв. ФС! Делать выводы о суперблоке для smbfs на основе этого
файла -- глупость!

Вообще-то указанный файлец довольно занимательный -- он определяет работу самого верхнего уровня
абстракции в ФС. Абстракции ядерного уровня. И не только он. К примеру, fs_struct.h. Там, к
примеру, выставляется root filesystem... Т.е. именно та ФС, которая будет монтироваться в
каталог / и в которую будут монтироваться остальные ФС.

Кстати, в этом же файле (fs.h) Вы увидите VFS helper functions. Когда Ваш процесс чего-то
делает с файлецом, то вызываются именно эти функции. А вот далее, в зависимости от того, каково положение
целевого файла, вызывается обработчик той ФС, которая нам нужна в данном случае. И который, кстати,
реализует логику работы целевой ФС. Это несколько упрощенная модель и прежде всего потому, что у
каждой ФС, расположенной "ближе" к подмонтированному разделу есть свой суперблок, определяющий
имено какие-то специфичные для данной ФС моменты. На более низких уровнях абстракции, если мы об
"абстракциях".

См. подкаталоги соотв. ФС в /usr/src/linux-/fs. Даже простенькое сравнение подкаталогов по
составу файлов наталкивает на некие интересные мысли. А, если начинаем сравнивать те же каталоги по
размеру, то получается вообще всё интересно... См. ниже.

Только не надо мне рассказывать, что сравнение по размеру ничего не доказывает. Это куски кода, который
исполняется всякий раз, когда Вы чего-то пишете в файл, к примеру. Ха! Есть и другие аспекты и мы
рассмотрим их ниже -- в частности, производительность при чтении ФС. Их-то этот код и реализует и
там он выгоден. А пока вернёмся к нашим структурам ФС. И, в частности, к суперблоку. Выводы по скорости
записи в файл здесь напрашиваются сами, не так ли?

Чем ещё это все интересно. Не так прост этот самый суперблок. Что происходит, к примеру, при потере
питания? Комп. гасится, но в этот момент не происходит выполнения синхронизации буферов ФС и
содержимого раздела диска. Т.е. не происходит выполнения команды sync/fsync и демонтажа
ФС. Т.е. при следующем включении система делает вывод о том, что суперблок необходимо восстанавливать
и запускает fschk (там есть "флажок", который система проверяет и на основании его состояния
принимает решение -- восстанвливать структуру или нет). Видели, наверное, к чему это ведет... И не
раз... :D По этой-то причине я и говорю о том, что любая UNIX-система должна быть хорошо защищена по
питанию. Они в таких случаях все ведут себя одинаково. Правда, журналирующие ФС приятное исключение,
но... У всего есть свои минусы...

Ладно. Далее. Получается, что у VFS есть некоторые дисковые буферы для кеширования дисковых
данных. И верно -- есть. См. сырцы. Больше на имена файлов не ссылаюсь, IMHO, понятно. Именно эти
буферы и должны периодически сбрасываться на диск в процессе нормальной работы через определённые
промежутки времени и полностью зачищаться при остановке системы.

Кстати, в той теме, которая меня сподвигла на написание этой, я говорил о том, что для "ушустрения"
работы ФС требуется уменьшить один из временных параметров. Что это за параметр см.
/usr/src/linux-/fs/buffer.с. Он относится к VFS.

Просмотреть значения можно:

$ cat /proc/sys/vm/bdflush

Шестая слева цифирь -- оно и есть. Это параметр, указывающий демону ядра bdflush как часто
сбрасывать данные из неиспользуемых буферов на диск. Он относится к подсистеме виртуальной машины,
по этой причине и хранится в указанном выше каталоге. Собственно, команда sync/fsync (см.
утилита update -- здесь можно поменять) ему и дают команду сбросить буферы. Ранее уже
обсуждалось, так что батоны прессовать по этому поводу ещё раз, IMHO, излишнее, господа.

Для более близкого знакомства с ФС есть фунции С statfs/fstatfs.

- i-node.
Суперблок содержит в себе данные о логической структуре диска, образованной i-node'ами или,
проще, индексными дескрипторами. Кстати сказать, практически все ФС UNIX-систем
относятся к т.н. inode filesystems.

Что это. Это описание какого-то конкретного элемента ФС (будь то файл или каталог, или символическая
ссылка), которым может управлять ФС. Для VFS inode содержит ряд параметров, характеризующих
подмонтированную ФС. Для подмонтированной ФС все несколько по-интереснее. Там хранится инфа о
размещении файлов/каталогов по блокам, размер файла, симв. ссылки, ID пользователя, группы, защита,
тип файла, время создании/модификации/последнего доступа, ....
Вообще-то для более близкого знакомства с inode'ами есть хорошая функция языка С -- stat
(lstat/fstat). :D Ближе, IMHO, некуда... :D

- блоки.
Это просто отдельные элементы хранения любых данных, которые могут храниться в ФС и которые
учитываются в inode. Точнее, это -- filesystem block. Размеры блоков могут варьироваться
как правило, от 1К до 4К. Здесь важен ряд моментов:

- при планировании ФС все-таки лучше себе чётко представить -- какой процент данных будет более
полно укладываться в некоторое число, кратное размеру блока. Чем ближе Вы угадаете, тем больше места
будет использоваться максимально эффективно. Ну, наверное, понятно, что мэйл-сервер и сервер БД
работают с различными по размеру файлами и, как следствие, размеры блоков нужны различные. Если
для первого случая не плохо было бы 1К поставить, то для второго и 4К не жаль. На десктопе у меня
1К и... все нормально... Не жужжу... :D Единой методики для "угадывания" просто нет.

- как обрабатываются блоки. См. ниже.

Есть ещё такие элементы как каталоги, сиволические ссылки. И, вполне возможно, может
использоваться ряд других элементов конкретной ФС, но нас в данный момент они мало интересуют. Т.е.,
определяется как именно должны храниться каталоги -- выделяется ли для них отдельное место в пределах
ФС или нет, они хранятся в inode'ах (в ext2, к примеру). Как хранятся символические ссылки --
выделяется ли для них отдельное место и где. К примеру, в ext2 ФС не выделяется -- они хранятся там
же в inode.

Гораздо интереснее с точки зрения скоростных характеристик ФС другое -- (preallocating
techniqe) -- как и что из данных кэшируется. Т.е., к примеру, система должна прочесть некоторый
файл, занимающий N блоков. Ок. Как и что будет кэшироваться -- список блоков, который нужно прочесть
или содержимое этих самых блоков?

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

Далее кэшироваться могут каталоги. Это значит, что поиск файлов может осуществляться более быстро,
нежели при отсутствии такового (и вопрос, кстати сказать, как именно кэшируются каталоги, к примеру,
в reiserfs используется вариант двоичного дерева, что несомненно ускоряет поиск как в кэше, так и
формирование кэша из таблиц на диске). Есть ещё ряд тонкостей, характерных для различных ФС.

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

Я могу обосновать только свою позицию по данному вопросу -- дело в принципе KISS,
точнее в следовании ему. Я не считаю нужным тратить ресурсы своей системы на то, чтобы
пользоваться тем, что мне не нужно, т.к. лишние для меня возможности -- лишние такты и байты памяти
моей машины. Если простая ФС мои задачи решает, то зачем мне сложная? Откуда убежденность
в том, что, даже, скажем, я сделаю свой сайт, то он будет суперпопулярен и именно "производительность"
ФС при поиске/чтении документов с винта будет "бутылочным горлышком" всей системы?

IMHO, если кто-то хочет использовать более сложную ФС и может обосновать это, то почему бы и
нет? :D Принцип KISS не догма, а руководство к действию, не правда, ли? :D

Далее. Я не отрицаю и не думаю даже спорить с тем, что в ряде случаев более новые ФС могут превзойти
ext2. Но я и не собираюсь спорить с тем, что программисты только и делают, что совершают
ошибки и забывают чего-то тестировать... :D По этой причине, я не доверяю всем последним пискам
моды и суперновым технологиям. :D Они должны пройти "обкатку", обрасти доп. возможностями, пакетами,
а дальше -- поговорим. На данный момент самая старая из ФС (ext2) -- самая проработаная в этом плане
ФС. Для неё есть ряд доп. пакетов, реализующих (здесь не всё из возможного):
- прозрачная компрессия -- ftp://opensource.captech.com/e2compr/
- дефрагментация -- ftp://ftp.uk.linux.org/pub/linux/sct/defrag/
- изменение размера раздела -- http://www.dsv.nl/~buytenh/ext2resize/
- редактор раздела -- http://sunsite.unc.edu/pub/Linux/system/Filesystems/ext2/
- undelete -- http://amadeus.uprm.edu/~undelete
- ...

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

2. Сводная "табличка" ФС.
В "таблицу" сведены три ФС -- ext2, ext3, reiserfs.
2.1 "Filesize".
Вы говорите это неважно? Хмммм... Поглядим...
- ext2 -- 11 файлов сишных сырцов, 127 386 байт.
- ext3 -- 10 файлов, 230 385 байт.
- reiserfs -- 22 файла, 681 073 байт...
Ула-ла... :D
Ээээээ... Правда "неважно"? Серьёзно? ;)

2.2 Возможности.
2.2.1 ext2/3.
Если не рассматривать "журналирование", необходимого для восстановления ФС (прежде всего!) ext3
является расширением ext2. По этой причине мы можем считать их одной системой в том, что
касается иных параметров, в частности, физической структуры базовых блоков, inodes, каталогов.

Итак, ext-ФС решают сходные задачи по оптимизации операций чтения/записи данных. При записи данных
резервируется до восьми блоков на винте с тем, чтобы разместить данные по возможности более плотно.
Действительно, имеет смысл, т.к. в этом случае, при чтении, головкам винта не надо будет долго
парить над поверхностью с тем, чтобы считать очередной блок. Блоки будут располагаться практически
рядом. Проблема дефрагментации возникает, если файлы не помещаются в выделенные блоки и начинают
дробиться на восьмиблоковые куски. Вот только ext3 ещё должна сделать "пометки" в журнале... :D

При чтении файла все несколько интереснее. Так же, до восьми блоков одного файла (если есть в файле
столько блоков), будут последовательно считаны в буфер ядра. Это делается по причине того, что если
считан один блок данных из файла, то, если там более одного блока, с высокой вероятностью потребуются
и последующие. Размер блока определяется при создании ФС -- 1К, 2К, 4К.

2.2.2 reiserfs.
Самая главная особенность -- не журналирование, IMHO, а упорядочение данных. Сразу. При записи. И
расширенные возможности кэширования данных.

Журналирование вообще -- вкусный крем поверх пирожка. В любом случае, при записи данных, существуют
задержки в журнале ФС и журнале транзакций, которые обеспечивают отказоустойчивость системы. Дело
в том, что при аварийном останове системы, после её запуска, система делает попытку вначале провести
в журнале блоков транзакции из журнала транзакций, а потом попытается из журнала блоков перенести
успешные операции записи в ФС. Это выглядит здорово, пока я не подумаю о накладных расходах на операции
записи, т.к. мало пары журналов, так ещё при записи ФС строит двоичное дерево файлов/каталогов и
отображения их на пространство inоdes. И упорядочивает его по мере необходимости. Создали файл/удалили
файл, должна вычислиться соотв. хэш-функция... :( Записали чего-то/удалили чего-то... Записи в
журнале транзакций, при закрытии -- перенос их журнал блоков и, в завершение, в систему... Хэш-функции
так же считаются, т.к. без них в b-tree никуда... :(

Для того, чтобы всё не бвло бы всё очень "грустно" в смысле производительности ФС, размер блока
установлен в 4К, т.к. если поставить 2К или 1К, то объём вычислений остаётся большим, а вот объём
записываемых данных уменьшается. См. выше -- хорошо это или плохо -- 4К.

Кстати сказать, то, что русские программисты приняли самое активное участие в этом проекте, вызывает
дополнительную гордость. Проект (как идея, так и реализация) -- просто класс. Тут M$ обещает в
новой ОС какую-то очередную революционную ФС, имеющую возможности "базы данных" при поиске файлов...
Меня гнетут смутные сомнения, что я знаю где они скоммуниздили, если не сам релиз (было бы грубо),
так идею... :D

Да! И, кстати, о "дефрагментации"... Угадайте -- по сколько блоков система пытается читать/писать
данные? :D

3. Куда бежать?
А никуда не надо бежать. Если Вас гнетут размышления на тему, какая же ФС лучше, то я могу сразу
сказать -- все. И никакой. Смотря для чего. Во всём есть свое рациональное зерно и однозначный
ответ Вы можете получить только от "специалиста по маркетингу", а не "технаря". Лично мне непонятна
гонка "ядер", при которой народ только и делает, что апгрейдит и преустанавливает систему. Ааааа...
Когда работает? Т.е. когда делает то, за что ему (народу) платят "бабки"?

Точно так же не ясны побудительные мотивы в гонках ФС. Т.е. получается, что как только выходит
новая ФС я её должен поставить? Аааа... Зачем? Меня и старая более чем устраивает и, если
я добавлю "больше объёма, больше блеска" в свою систему, то не заторможу ли я систему? Ладно...
Где-то с DEiL'ом мы это уже обсуждали. Раньше было...

Да и потом -- в ядре колупаться дело благородное. Но деньги я зарабатываю не этим. Когда приходят
какие-то идеи, я, по мере возможности, стараюсь их реализовать (для себя). Вот, в принципе, и всё.
Для выпусков новых public-версий/патчей для старых есть народ, именуемый kernel-hacker'ами.
Я не из них, т.к. предпочитаю работать в режиме private. Ладно, Бог бы с ним со всем.

Давайте лучше разберем несколько примеров. Хотя, я хочу подчеркнуть -- различия между всеми этими
ФС настолько малы, что проявляются только при весьма значительной нагрузке на них. И,
зачастую "суровая" оптимизация ничего не даёт кроме траты времени. Как, к примеру, я его сейчас
трачу... :D

Ещё один важный момент -- какова вообще-то хост-среда на рассматриваемой в каждом примере машине и
каковы программные технологии, используемые для доступа к файлам? Только ли то, что указано, или
ещё чего-то "болтается"? В принципе, я видел... Хммм... "Оригиналов", у которых на одной машине
крутились и самба, и прокс, и весь мэйл-сервер, и тут же были "прикручены" iptables, webmin, swat,
Apache, MySQL, ... Ещё Бог знает чего... По-моему, вообще, всё, что только было возможно и
невозможно... Но основной софт (за что платились деньги) был написан на... крепитесь, люди, на...
FoxPro с... "ассемблерными вставками"!!! Я не шучу это -- цитаты! Ж~D

При этом было ещё два сервера (под Windows и под Novell), на которых смотрели как на священных коров.
Попытки предложить распределить функции Linux (снеся хотя бы Novell, т.к. Windows была "Корпоротивной
Политикой", а Linux только-только пробивала себе дорогу) воспринимались как жутчайшее святотатство.

И которые при всём при том... старались оптимизировать систему... Переписав какие-то
жутко "секретные системные параметры, которыми с ними хакеры поделились". Ж~D А ещё им нехватало
"блокировок на уровне записей в .dbf-файлах в Самбе"... Как вспомню, так lol!!! Особенно то, как
сии доблестные викинги Фокспры и ассемблера заколёбывали своим сканированием внутренней сети...
Организацией "туннелей" через наш прокс. И как всё было весело, когда я, как админ, просто рубанул к
чертям собачьим всю их подсетку, хотя и не был особо жесток -- "отлучение от ИНета" было сделано в
терапевтических целях и всего на пару недель, опосля месяца уговоров вести себя в каких-то рамках и
отказаться (добровольно!) от особотяжких глупостей и излечиться от особовредных заблуждений -- ну,
хотя бы фигней с тоннелями не заниматься, т.к. от меня "наверх" должна уходить сводка чего, сколько,
откуда за месяц выкачалось всем заводом. А в их логах чётко просматривался тоннель, а меня
просто ломало в свои логи цеплять данные с их хостов (при всей общей "хакеранутости" всё-таки
это было возможно Ж~D). Порнухи там явно не было (на тот момент, когда проверял), а остальная хрень
типа patch'ей на одну из Linux-систем или новых SQUID'ов меня мало заботили... Так нет. Надо было
извратиться -- всенепременно тоннель организовать... Ж~D Тоннель хорош, когда админу не "в лом"
подняться парочкой этажей выше и просто на одном из хабов выдернуть шнурок, так... Чтоб конфиги не
править лишний раз... И всё -- "никто никуда не идёт"... Принцип KISS в действии... :D

Ладно, будет ужо над убогими ржать... :D Это не оффтопик! Это иллюстрация на тему
первичноси и вторичности задач. "Важного и неважного". Итак...

3.1 Если Вы ставите сервер для SAMBA + 1:C, то лучше Вам поставить ext2 или ext3.
Ответ прост. 1:С написана на M$ C/C++, использует т.н. базы данных ISAM (Index-Sequency Access
Method), так? Т.е. данные (при самой напряженной операции -- поиске, т.к. поиск идет по
индексному файлу, представляющему собой по идее, все тот же .dbf-файл, но только упорядоченый по
некоторому индексу) читаются последовательно, несмотря на все ухищрения.

Файлы достаточно большие. Т.е. нам все их в памяти держать смысла нет, т.к. это просто затормозит
работу при большом числе пользователей. Вообще, на мой взгляд, 1:С -- не самый лучший продукт.
Главная его прелесть в том, что он есть. Все остальное... Хмммм... Ладно. :D

Пользователи "ломятся" по smbfs, что ещё добавляет "радости", т.к. если "родные" Linux-ФС
ещё как-то кэшируют именно данные, то smbfs кэширует содержимое каталогов (имена файлов и
подкаталогов), обо всем остальном заботится VFS или root filesystem по запросу VFS.

Забыл сказать -- сервер защищен по питанию УПСом, демон apmd настроен, проведена проверка
реакции системы на отключение питания и полный разряд батарей. Система смогла автоматически
остановить ФС, корректно завершить работу. После включения питания все поднялось нормально.

Т.е., продолжая тему, получаем, что отключение питания нам не страшно -- УПС и apmd не
дремлют. Суперблок под защитой. С файлами более-менее разобрались. Теперь вопрос -- а какую же
все-таки систему выбрать-то -- ext2 или ext3. А вот здесь думайте сами -- чем шустрее
процессор, тем более сложную систему можно ставить. Хотя, в принципе, различия между ФС довольно
малы, но все-таки, они есть. См. выше.

3.2 Web-сайт (ftp-site). Причем, с серьёзной нагрузкой. Множество файлов, каталогов. Чем быстрее
сервант "отдаст" документ в полном объёме -- тем лучше. Никак нет возможности определить какой
документ (файл) в какой момент может быть затребован (классический случай случайного процесса).
Следовательно, чем быстрее будет найден документ (файл) и чем быстрее записан в сокет (отгружен
клиенту), тем лучше. А особо частоиспользуемые (во как! :D ) лучше бы вообще не скидывать из памяти...
:D Reiserfs, IMHO.

3.3 Сервант некоторой конторы, где водятся дятлы, до которых никак не дойдёт, что деньги на УПС'ы
тратить надо. Любая из систем будет слабо гарантировать защиту от отказов. Хуже всех, конечно
же -- ext2. Лучше -- reiserfs. Но не обольщайтесь -- всё до каких-то пределов...

3.4 Десктоп. Здесь всё интереснее. С одной стороны -- reiserfs, как самая кэширующая и
скоростная на чтение ФС, с другой стороны -- ext2/3 ФС. Сразу вопрос -- как насчёт УПСа?
Далее -- какие всё-таки задачи решаются? Какие размеры файлов в среднем? Как много файлов (склонны
ли Вы устраивать на своём винте файловые "помойки")? А, может, у Вас на машине будут "крутится"
какие-то серверы, работающие на всё предприятие в общем и целом (ведь в UNIX любой хост может быть
как клиентом, так и сервером)? Словом, вот этот вариант всё-таки по-сложнее любого другого будет.
Как я его решил -- см. выше. Как Вы решили -- дело Ваше. :D

А, вообще, если есть желание реально ускорить дисковую подсистему, то просто поменяйте
винты с IDE или аналогичных, на SCSI. Не прогадаете, говорю на основании собственного опыта, т.к.
при любом раскладе IDE-винты только приближаются по своим характеристикам к SCSI. Здесь
играет роль ряд факторов -- и наличие на контроллере SCSI буфера памяти (в те времена, когда я
с ними "резвился", до 16 MB было, как сейчас -- посмотреть спецификации надо бы), и сама по себе
более быстрая шина, ... Ну не настолько же гениальны Apple'овцы, чтобы самим разработать SCSI и
не настолько тупы, чтобы не ставить его на свои системы. А посмотрите на Mac'и, там практически
вся дисковая подсистема, в т.ч. и CD-ROM построены на SCSI. И не зря.

Хочу сразу предостеречь от "тонкой настройки" дисковой подсистемы через hdparm. Иногда
встречаются бредовые идеи по "разгону" дисков и "оптимизации доступа" через выставление
принудительно через hdparm параметров доступа. Это, по сути дела, род "разгона". Всё это
здорово, но этак можно получить режим работы, который Ваша система не воспримет как корректный.
Ну, при установке системы, ведь уже выставились некоторые параметры, которые систему удовлетворяют,
чего ещё-то надо? Слишком хорошо -- оно то же не хорошо, IMHO. Дело в том, что при таком раскладе,
можно "на раз" "убить" винчестер. Вам это надо? Хотя, если Вы хотите hardcore'ных экспериментов,
то такая возможность есть... Почему бы и нет? :D

4. Библиография.

- /usr/doc/Linux-HOWTO/Filesystems-HOWTO. Документ, на мой взгляд, не
полный, но основная идея -- продемонстрировать как и с какими ФС можно работать.
Даны краткие характеристики некоторых ФС. С этими задачами документ справляется
на все 100%. Почитайте -- не пожалеете.

- "The Linux Kernel" by David A Rusling. "Теоретические основы" можно
найти именно здесь, но моя версия документа слегка устарела.

- как всегда в подобных случаях -- /usr/src/linux-.
Здесь интересно следующее -- /Documentation/filesystems, /fs,
ряд подкаталогов в ветке /include... Сырцы ядра, короче, ждут Вас. :D

PS
Весь объём данных одному "поднять" просто невозможно. За скобками остались ещё
интересные ФС, да и многие особенности этих трёх ФС. Читайте, разбирайтесь... Всё в
Ваших руках.

Я никого ни за какую ФС не агитировал! Всё вышесказанное, господа, не более чем моё
IMHO!

Успеха! :D