Как разделяют пингвинов. Часть 2.

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

Файловые системы: что посеешь, то пожнешь

Под файловой системой понимается физический способ организации данных на дисковом разделе - возможность их хранения, нахождения и манипулирования ими (запись, стирание). Я думаю, такого простенького определения достаточно, чтобы понять, какие требования выдвигаются к ФС. До недавнего времени в Linux к услугам пользователей предлагалась только одна ФС - ext2fs, предоставлявшая возможность взаимодействовать с ФС других ОС, расположенных на одном диске. Посмотреть перечень таких ФС можно, набрав #make xconfig и зайдя в пункт меню File system. Для включения поддержки их ядром последнее необходимо пересобрать, активировав необходимый пункт. В современных ядрах Linux добавилась возможность работы с различными журналируемыми файловыми системами: ext3fs, ReiserFS, XFS и JFS. Для тех же, кому нужна более гибкая в конфигурировании и быстродействующая файловая система, появилась возможность создавать программные RAID-массивы (раздел raid auto, идентификатор fd) и системы управления логическими томами (LVM, идентификатор 8e). Кроме того, те, кому нужна повышенная конфиденциальность информации, хранимой на компьютере, могут воспользоваться CFS, свободной криптографической файловой системой для Unix/Linux от Матта Блейза (Mutt Blaze). В этой и последующих статьях будут рассмотрены только классические файловые системы, чаще всего применяемые на ПК.

Она была первой: Ext2fs

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

Еще одной ее особенностью является тройная косвенная адресация для указания расположения блоков больших файлов. Выглядит это примерно так. Если файл маленький, то в его метаданных содержится прямая ссылка на ячейки, в которых хранятся данные (логические блоки). Это прямая адресация. При увеличении же объема файла до некоторой критической величины занимаемое им место не удается адресовать с помощью прямой адресации. Блоки метаданных указывают уже на косвенные блоки, в которых содержатся адреса с данными, определенными в файле, или опять же указатели на следующие косвенные блоки. Количество таких косвенных блоков для одного файла может достигать трех. То есть если файл увеличивается в размере, внешне это выглядит как единичная операция, внутри же несколько иначе: поначалу распределяются новые блоки, чтобы принять новые данные, затем модифицируется inode, чтобы сделать запись о новых указателях и новых размерах, затем наконец производится запись данных.

Вот теперь представьте, что будет, если при записи файла произойдет сбой. Возможен вариант, когда запись уже произведена или еще не начиналась. Это самый благоприятный вариант: в первом случае после перезагрузки вы так и будете работать с документом, ну а во втором случае потеряется пару часов работы, но с файловой системой ничего страшного не произойдет. А вот если система "упала" именно в момент сохранения файла, то это худшее из того, что могло произойти. Если запись производилась в зону метаданных, то теперь информация, содержащаяся в них, не будет соответствовать реальному расположению файлов на диске. Ситуация усугубляется еще и тем, что Linux, в отличие от Windows, не обязательно записывает обновленный файл поверх старого - при записи во избежание фрагментации выбирается такое место, чтобы он влез полностью. Потому-то в этой системе нет программ-дефрагментаторов (мне доводилось наблюдать фрагментацию данных максимум 0.5%, да и то на переполненном диске, что, согласитесь, очень мало). Так вот, если данные заносились в каталог - а ведь это тоже файл, - то после перезагрузки мы можем недосчитаться одного каталога или, что еще хуже, целого раздела. Ну а если произошел сбой при записи в область данных, то что он будет потом содержать, зависит от вашего везения, особенно в случае, если производилась запись поверх старого варианта файла. Конечно, ситуация не так плачевна, как я обрисовал. За все время активной эксплуатации системы, пережив вместе с ней не одно выключение электропитания, случаев, из ряда вон выходящих, не было (тук-тук-тук).

Естественно, для данной файловой системы (это я все еще о ext2fs веду речь) были разработаны утилиты, помогающие восстановить ее после сбоев. За несколько лет их алгоритм, в отличие, от всеми любимого Scandisk'a, не поленились довести до почти совершенства. Так как проверять при каждой перезагрузке все диски, установленные на компьютере, согласитесь, накладно по времени, нашли такой простой выход. После того как все данные согласованы, непосредственно перед самым ее размонтированием устанавливается clean bit (в Windows также используется аналогичная технология). Перед загрузкой системы перед ее монтированием программа fsck (FileSystem ChecK) просто проверяет его наличие; если бит установлен, то делается вполне разумное предположение, что файловая система находится в непротиворечивом состоянии, а если нет, то запускается изрядно всем надоевшая утилита fsck (scandisk, по-Microsoft'овски). В связи с тем, что ext2fs содержит избыточные копии критически важных метаданных, вероятность полной потери данных чрезвычайно мала. Система определяет местонахождение поврежденных метаданных и потом либо восстанавливает данные, копируя их из резервных копий, либо просто удаляет файл или файлы, чьи метаданные пострадали. Точнее, не удаляет, а переносит их в каталог /lost+found. В этом-то и состоит очевидное неудобство: согласитесь, что чем больше файловая система, тем дольше длится процесс проверки. На дисковом разделе размером в несколько гигабайт, что давно уже перестало быть редкостью, с большим количеством файлов и каталогов, процедура проверки метаданных во время загрузки может очень сильно затянуться. А если выбило главный производственный сервер, и теперь пользователи вынуждены ждать, пока он перегрузится? Вот так мы плавно подошли к журналируемым файловым системам.

Что есть журнал?

Вся волшебная сила журнала заключена в механизме транкзаций - этот термин неплохо известен тем, кто работал с базами данных. Как и там, механизм транкзаций вместо отслеживания модификаций к таблицам и данным, рассматривает операцию записи на диск как атомарную, а не разделенную на несколько этапов, что позволяет отследить, прошла ли запись вообще, и в свою очередь гарантировать, что изменение файловой системы произведено полностью или не произведено вообще. Поясню сказанное на примере. Например, при создании нового файла изменяются несколько структур метаданных (inodes, списки свободных блоков, список файлов каталога и др.) Прежде, чем в файловой системе произойдут изменения, создается транзакция, в которой описывается то, что должно быть сделано. Как только транзакция будет зарегистрирована (на диске), файловая система приступает непосредственно к изменению метаданных. То есть фактически журнал в такой файловой системе - просто список производимых операций. В случае системного сбоя файловая система будет восстановлена к непротиворечивому состоянию путем повторного запуска журнала и отката к предыдущему состоянию. К тому же в таком случае файловая система осматривает только те участки диска, в которых изменялись метаданные, т.е. она уже "знает", где произошел сбой. Это намного быстрее, чем при традиционной проверке с помощью fsck. И что самое существенное, время восстановления совсем не зависит от размера раздела - скорее, от интенсивности операций на момент сбоя.

Можно выделить два возможных варианта работы журналируемой файловой системы. В первом варианте в журнал заносятся только изменяемые метаданные файла, в таком случае при сбое будет гарантированы метаструктуры файловой системы, а сохранность самих данных уже зависит от везучести. Второй вариант предусматривает занесение в журнал вместе с метаданными также и самих данных, как изменившихся, так и не модифицированных, в этом случае есть вероятность, что данные после сбоя будут восстановлены. И конечно же, как говорил мой преподаватель по теоретическим основам электроцепей, "природу не обманешь, за все нужно платить", а платить теперь приходиться быстродействием, так как самые медленные операции в компьютере - это операции ввода/вывода на диск, а количество таких операций возросло, особенно при использовании варианта с журналированием данных. Решают вопрос разными ухищрениями: например, запись происходит в момент наименьшей активности, некоторые журналируемые файловые системы позволяют разместить журнал на другом физическом диске. Да и фактически время работы с журналом намного меньше, чем работа непосредственно с данными. И естественно, некоторый полезный объем теперь приходится отводить под сам журнал, но его размеры как правило не превышают 32 Мб, что по нынешним временам не так уж и много.

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

Большинство современных journaling файловых систем поддерживают:

более быстрое распределение свободных блоков; для этого большинство из них построено на основе сбалансированных деревьев, иначе известных как B+ деревья. О том, что это такое, лучше спросите у авторов, пишущих о различных языках программирования, особенно об алгоритмах поиска и сравнения, а особо любопытные пусть посмотрят документ по адресу http://starship.python.net/crew/aaron_watters/bplustree/bplustree.py.txt;

большее количество файлов в каталоге: поскольку обычная связка name-inode становится неэффективной, то опять же для хранения имен файлов используются B+ деревья. В некоторых случаях возможно использование всего одного B+ дерева для полной системы, что намного укорачивает поиск файла и, соответственно, операции по работе с ним. Плюс динамическое выделение inides вместо неэффективного статического;

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

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

Система в красной шапке: Ext3fs

Хотя данная файловая система не была первой, поддерживаемой ядром Linux официально (появилась только с версии 2.4.16), все таки я думаю, что справедливо будет начать именно с нее. Разработана она в недрах компании Red Hat (там и следует искать всю информацию о ее работе) доктором Стефеном Твиди (Stephen Tweedie). Найти патчи для ядра можно по адресу ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs. Чтобы не изобретать колесо, поступили просто, прикрутив к стандартной ext2fs журнал (в зависимости от опций монтирования, его можно и не видеть; находится в ./.journal) и заменив драйвер ядра, отвечающий за файловую систему. По этой причине она, естественно, наследует все достоинства и недостатки, присущие ext2fs . Но что это дало?

Самое главное - это то, что утилиты ext2fs, которые шлифовались в течение нескольких лет, работают в ней как ни в чем не бывало. К тому же идентичность файловых систем позволяет оперативно переходить как с еxt3fs на ext2fs, так и наоборот. Поясню. Мне часто приходится устанавливать другие дистрибутивы, в том числе и со старыми ядрами, не поддерживающими новинку. Так вот, все разделы, на которых используется ext3fs, я монтирую просто как ext2fs - и никаких, повторяю, никаких недоразумений при использовании не происходит.

Другое преимущество данной файловой системы состоит в том, что она, в отличие от остальных, поддерживает режим журналирования данных (полное или частичное). Естественно, добавление журнала, казалось бы, должно было ухудшить производительность такой системы по сравнению с "нежурнальным" вариантом. Оказалось, что за счет улучшения алгоритма движения головки жесткого диска данная файловая система в некоторых случаях даже обходит ext2fs. Ext3fs имеет три режима работы:

data=writeback - режим, при котором не выполняется никакого журналирования данных, учитываются только метаданные - самый ограниченный режим журналирования (кстати, применяемый во всех других ФС рассматриваемых ниже), не гарантирующий сохранности данных после сбоя. Но за счет этого возрастает скорость работы такой файловой системы: фактически журнал предназначен только для того, чтобы уменьшить время начальной загрузки системы;

по умолчанию же используется data=ordered - золотая середина между полным журналированием данных и предыдущим режимом. Официально в этом случае журналируются только метаданные, но блоки соответствующих им данных записываются первыми. В большинстве случаев такой режим гарантирует сохранность данных, особенно если данные дописывались в конец файла, чего в большинстве случаев предостаточно. Производительность, естественно, чуть ниже предыдущей и выше

режима полного журналирования - data=journal, - в котором все новые данные сначала пишутся в журнал и только после этого переносятся на свое законное место. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние. Кстати, как оказалось, данный режим в случае, когда диск интенсивно загружен операциями IO, оказывается даже быстрее всех остальных.

Выбрав режим, отличный от установленного по умолчанию, необходимо указать его с помощью опции -o. Например:

Или в /etc/fstab:

Если же теперь захочется отказаться от него, то, исправив ext3 на ext2, можно забыть о журнале:

Для того чтобы к обычной ext2fs добавить журнал, достаточно выполнить команду

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

Начиная с версии 0.9.5, ext3fs может использовать другой диск для хранения файла журнала. Подробности можно узнать по адресу http://www.zipworld.com.au/~akpm/linux/ext3/ext3-usage.html.

Вот и все о данной файловой системе. От себя хочу заметить, что разделы /home, /usr/local, которые часто приходится монтировать к другим Linuxам, у меня отформатированы именно под ext3. Что и говорить, это предсказуемая и, главное, УДОБНАЯ файловая система. Характеристики относительно максимального количества файлов и каталогов, а также максимальных размеров разделов меня полностью устраивают. Но у нее есть один наследственный недостаток, который практически полностью решен в другой ФС.

ReiserFS

Это первая "сторонняя" файловая система, появившаяся в официальном ядре 2.4.4. На первое время ее работа вызывала одни только нарекания, поэтому ее использовали только любители острых ощущений. Данный проект стартовал в 90-х годах, первый прототип носил название TreeFS. Разработана Хансом Райзером (Hans Reiser) и его компанией Namesys (http://www.namesys.com), причем задачи они перед собой поставили очень, я бы сказал, революционные. Разработчики системы мечтают создать не только файловую систему, но вообще механизм иерархического именования объектов. Они считают, что лучшая файловая система та, которая формирует единую общедоступную среду - namespace. Для этого файловая система должна выполнять часть работы, традиционно выполнявшуюся приложениями, что уменьшит количество несовместимых API узкоспециального назначения. При таком подходе пользователи смогут продолжать прямое использование файловой системы без необходимости формировать уровни специального назначения, типа баз данных и т.п. А вообще, зайдите на сайт, благо из всех подобных проектов этот наилучшим образом документирован. Но предупреждаю, документации там много. Базируется она на оптимизированных b*-сбалансированных деревьях (одно на файловую систему), использование которых кроме увеличения производительности снимает ограничение на количество каталогов (хотите 100 тыс. - без проблем!) На данный момент поддерживает журналирование только метаданных, но разработчики обещают в скором времени предусмотреть и режим, аналогичный data=journal в ext3. Преимущества данной ФС в основном проявляются в работе с маленькими файлами. Поясняю. Как я уже говорил, информация на физическом носителе хранится не как попало, а отдельными блоками, размер которых зависит и от размера раздела (это связано с максимально возможной адресацией) в том числе (устанавливается при форматировании), но в большинстве случаев равен 4 Кб. Так вот, еxt2 (ext3 и FAT тоже) могут адресовать только целое количество блоков. Ну и что? Имеем файл 10 Кб, размер блока 4 Кб. Получается, что файл займет 2 целых блока и один только на половину - 4+4+2 (2 осталось незанятыми, это и называется внутренней фрагментацией). Для единичного файла это не страшно, но если их несколько тысяч? По подсчетам, в этих ФС теряется где-то от 6 до 10 процентов. Кстати, Fast File System (FFS), применяемая в BSD, умеет адресовать субблоки, а во всеми любимой FAT придется мириться с неизбежной потерей места. Разработчики ReiserFS решили отказаться от решения вереницы противоречивых задач, сосредоточившись на одной. ReiserFS может запросто упаковывать несколько маленьких файлов в один дисковый блок (tail packing), а совсем маленькие вообще просто запихать в inode (внутрь b*tree). По необходимости для файла может ассигноваться точный размер. Такой режим работы предусмотрен по умолчанию, но для повышения быстродействия есть возможность ее отключить. Хотя показатели ReiserFS при работе с большими файлами довольно высоки, именно работа с маленькими файлами (меньше Кб) и обслуживание большого их количества выделяет данную ФС. По работе с ними она превосходит по быстродействию все представленные файловые системы (видел цифры: в 8-15 раз), именно за счет того, что данные и метаданные хранятся рядом, но с "разреженными" файлами работает все-таки хуже (это, как ожидается, будет исправлено в четвертой версии, ожидаемой 30 июня 2003 года). Плюс, как видите, достигается значительная экономия дискового пространства. Различные источники называют ReiserFS самой устойчивой из всех рассматриваемых ФС; ее, я думаю, можно рекомендовать для корневого раздела, который к тому же состоит из маленьких файлов. Такая себе рабочая лошадка. Но для работы с данной ФС, кроме поддержки ее самим ядром, необходимы также специфические утилиты для работы и обслуживания разделов - они уже входят в стандартную поставку всех современных дистрибутивов, а если нет, то можете взять их по адресу ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.4.tar.gz.

Если ядро уже поддерживает ReiserFS и имеются необходимые утилиты, то набрав

можно создать на ней соответствующую файловую систему. Для автоматического монтирования ее при загрузке достаточно прописать в файле /etc/fstab

или

при монтировании вручную. Если для увеличения производительности необходимо отключить упаковку хвостов, то добавьте опцию notail:

А опция -genericread может увеличить производительность при операциях поиска файлов, т.е. когда головка мало считывает, но много перемещается по диску.

XFS

Основа этой файловой системы была создана в начале 90-х (1992-1993) фирмой Silicon Graphics (сейчас SGI) - чувствую, как напряглись те, кто занимается графикой, - для мультимедийных компьютеров с ОС Irix, заменив уже не удовлетворявшую требованиям времени EFS, но немного "очищенная" версия 1.0 стала доступна только первого мая 2001. Найти все необходимую информацию можно по адресу http://oss.sgi.com/projects/xfs. Файловая система была ориентирована на ну очень большие файлы (9 тыс. петабайт - 9 млн. терабайт - 1018 байт) и файловые системы (18 тыс. петабайт) - в отличие от предыдущих, она является полностью 64-битной, что позволяет адресовать большие массивы данных. Особенностью этой файловой системы является устройство журнала - в журнал пишется часть метаданных самой файловой системы таким образом, что весь процесс восстановления сводится к копированию этих данных из журнала в файловую систему. Размер журнала задается при создании системы, он должен быть не меньше 32 мегабайт (больше, наверное, и не надо - такое количество незакрытых транзакций тяжело получить). Тесты на производительность показывают бесспорное преимущество XFS, особенно при работе с большими и средними файлами. Также эту файловую систему характеризует прямолинейность падения производительности при увеличении нагрузки и предсказуемость - дополнительно она не генерирует излишнюю дисковую активность, т.к. пытается кэшировать как можно больше данных и "основанием" для сброса на диск является заполнение памяти, а не интервал времени, как это принято в других ФС. Любое дисковое устройство при создании файловой системы XFS разбивается на несколько равных по размеру линейных областей (0.5-4 Гб), в терминологии XFS они именуются allocation group. Уникальность allocation group в том, что каждая группа управляет своими собственными inodes и свободным местом, что превращает группы в своего рода автономные файловые системы, сосуществующие в рамках общей XFS. Такая организация позволяет эффективно организовать параллельную обработку операций ввода/вывода, которая особенно ярко проявляется на многопроцессорных системах. В каждой такой группе используется три В+-дерева, два из которых отвечают за свободные inodes (allocation). В этой системе реализована очень хорошая возможность, позволяющая избежать фрагментации файлов, называемая delayed allocation. При этом файловая система, получая данные для записи, по началу лишь резервирует под них необходимое свободное место, откладывая саму запись до момента фактического сброса данных. Когда же такой момент наступает, XFS решает, куда необходимо их поместить. Если осуществляется дозапись, то подбираются соседние сектора. Но наибольший эффект от такой задержки получается еще и за счет того, что при создании временного файла с малым временем жизни последний вообще на диск не пишется (соответственно, не приходится занимать/освобождать метаданные). Для борьбы с внешней фрагментацией (это как раз то, против чего борются программы типа Norton Speed Disk) разработчики в ближайшее время планируют выпустить аналогичную утилиту. К сожалению, каноническим ядром пока данная ФС не поддерживается, хотя в экспериментальных 2.5.х версиях ядра поддержка ее уже включена, что позволяет надеяться на скорое решение этого вопроса, а некоторых дистрибутивах (Gentoo, Lunar Linux) она уже предлагается пользователю. Так что придется сходить на сайт разработчика за патчем (ftp://oss.sgi.com/projects/xfs/download) и необходимыми утилитами (как минимум xfsprogs) для работы с ней. Сейчас на сайте доступен релиз 1.2pre4, меньше 1.1 брать точно не стоит, в них были замечены некоторые ошибки, в частности, малая скорость удаления большого количества файлов. Теперь, пересобрав ядро и установив необходимые утилиты, можно создать файловую систему:

Для увеличения производительности в некоторых случаях может помочь опция -l size=32m, фиксирующая размер журнала (32 Мб), также с помощью -d agcount=x хорошо бы установить минимально возможное количество allocation groups (т.е. взяв максимально возможные 4 Гб на группу). Например, при разделе 18 Гб устанавливаем:

Необязательная опция -f позволяет создать XFS поверх любой существующей ФС, но при создании раздела поверх ReiserFS (и наоборот) необходимо заполнить нулями начальный раздел, содержащий метаданные перед переформатированием, т.к. команда mount может неправильно определить, какая из файловых систем установлена. Вот как это делается:

Прервать операцию секунд через 10 - 20 комбинацией Ctr+C. Смонтировать вновь созданный раздел теперь можно командой

Для повышения производительности можно задать некоторые опции noatime, nodiratime, osyncisdsync, вместе помогающие добиться асинхронного вывода информации и практически имитировать поведение ext2, а также logbufs, устанавливающую размер буфера (по умолчанию равен 2), - здесь особо усердствовать не стоит, например, 8 при 128 Мб оперативной памяти уже многовато:

Остальную информацию смотрите в каталоге /usr/src/linux/Documentation/filesystems, файл xfs.txt.

JFS (Journaled File System)

Первоначально создана фирмой IBM для своей OS/2 Warp, а затем выпущена по лицензии GPL и портирована под Linux. Всю необходимую информацию можно получить по адресу http://oss.software.ibm.com/jfs. По своим характеристикам и архитектуре очень схожа с предыдущей, поэтому вдаваться в подробности не буду. Как и в предыдущей, в этой файловой системе раздел логически подразделяется на "агрегаты", но последние включают, кроме данных, еще и отдельный журнал, при этом каждый из таких сегментов можно монтировать отдельно; также имеется возможность хранения маленьких файлов в пределах inode. Если катлог имеет до 8 файлов, то информация о них содержится в самом inode, при увеличении же их количества используются уже знакомые B+-деревья. По тестам это, наверное, самая медленная файловая система из рассматриваемых, хотя и разрабатывалась она для работы на высокопроизводительных серверах. Для установки необходима утилита jfsutils, патч к ядру jfs-2.4.х-patch и код ФС jfs-2.4-1.0.20.tar.gz. После установки и компиляции всех программ для создания раздела достаточно выполнить команду

и смонтировать ее:

Для возможности работы с внешним журналом необходимо два неиспользуемых раздела, например:

***

Как видите, ОС Linux предоставляет пользователю возможность выбрать даже файловую систему под конкретные задачи. И самое главное, необязательно, чтобы была установлена только одна из этих файловых систем. Например, для корневого раздела вполне подойдет ReiserFS, для /usr/local - ext3, а домашний каталог, битком набитый видео, можно отформатировать под XFS. В следующий раз поговорим об оставшихся утилитах и оптимизации работы диска. Linux forever.

Сравнение некоторых характеристик файловых систем:

+ Pb это 10^15 b
* Eb это 10^18 b
Но ядра серии 2.4.х имеют предел 2048 Gb. Обойти его можно, установив патч.

Навигация по статье:

Часть 1: Разделы
Часть 2: Файловые системы
Часть 3: Утилиты и оптимизация