Смотрим плавность хода с помощью BMW Rheingold

Всем знакома ситуация, когда двигатель немного "троит", но пропусков зажигания нет...

Дельта-синхронизация крипто-дисков

Существуют разные способы зашифровать "облако". Один из них - поместить в облако крипто-диск. В предыдущей статье мы писали, почему это не всегда удобно.

Дельта синхронизация без облака

Ранее мы показывали разные способы синхронизации криптодиска между ПК и Android-устройством.

Облачный хостинг VDS за 2 минуты

Настоящий облачный VDS-хостинг от UltraVDS: тестируем производительность

Какой журнал лучше?


Обычные файловые системы - или работа без журнала

Совсем недавно стандартной файловой системой Linux была файловая система ext2. С момента своего появления файловая система ext3 уверенно «набирала обороты» и если, скажем, года два назад никто бы не рискнул установить на сервер новую файловую систему ext3, то сейчас она используется в большинстве случаев. Программы установки практически всех дистрибутивов предлагают файловую систему ext3 по умолчанию. Файловая система ext3 появилась в составе Linux с момента выхода ядра версии 2.4.16. Впервые она появилась в дистрибутивах RedHat и SuSE.

Некоторые источники сообщают, что файловая система ext3 – это всего лишь «надстройка» над файловой системой ext2, а не самостоятельная файловая система. В этом утверждении есть доля правды. И в самом деле, файловая система ext3 совместима со всеми программами для обслуживания и настройки файловой системы ext2. Попробуем разобраться, так ли это?

Компьютер работает с данными в виде нулей и единичек. Все эти нули и единички записаны на жестком диске. Без файловой системы невозможно разобраться со всей этой кашей – непонятно, где начало, а где конец нужных нам данных. Поэтому, как только появились магнитные носители данные, записанные на этих носителях, объединялись в файлы. В принципе из одного байта уже можно сформировать файл. Помнишь, как к компьютерам подключались магнитофоны и данные записывались на обычную кассету? Это пример неиерархической файловой системы: файлы располагались на кассете последовательно. Чтобы перейти к нужному файлу, нужно было перемотать ленту. С появлением гибких и жестких дисков неиерархическая файловая система не оправдывала себя. Работа с такой файловой системой стала неэффективной. Во-первых, слишком медленные операции чтения, записи и поиска даже по меркам еще тех времен. Во-вторых, файлов стало так много, что держать их всех в одном каталоге стало просто неудобно, а если учитывать ограничение, которые накладывались на имена файлов, то при использовании большого количества маленьких файлом можно было даже превысить «алфавитный» предел для такой файловой системы: нельзя создать файл, потому имена будут повторяться. Конечно, вероятность этого события слишком мала, но все-таки есть. Учитывая все это, появились иерархические файловые системы, позволяющие объединять файлы в каталоги. Кроме того, иерархические файловые системы также позволяют хранить в каталогах и другие каталоги. Примером такой файловой системы может послужить файловая система ext3.

В начале файловой системы находится таблица размещения файлов, в которой прописаны физические координаты частей файла: ведь теперь файлы записываются не последовательно, поэтому обойтись начальным адресом и смещением относительно него уже нельзя: файловая система должна помнить, где находится каждая часть файла. Теперь разберемся, что такое целостность файловой системы. Файловую систему можно считать целостной, если один блок данных принадлежит одному и только одному файлу, то есть изменение одного файла или каталога не приводит к изменению другого файла или каталога. Иногда при проверке файловой системы в Windows иногда обнаруживается, что кластеры «пересекаются», то есть один кластер принадлежит двум или более файлам сразу. Обычно такие файлы нужно удалить, хотя есть возможность обрезать файл до момента коллизии, чтобы сохранить хоть какую-то часть файла. В случае с текстовыми файлами это помогает – хоть что-то да и останется, а вот двоичные файлы можно удалять сразу.

В начале каждой файловой системы есть «чистый бит». При подключении (монтировании) файловой системы этот бит стирается, что означает, что файловая система используется в данный момент. При завершении работы (размонтировании файловой системы) этот бит устанавливается, что говорит о правильном размонтировании файловой системы. Если при загрузке операционная система обнаруживает, что чистый бит не установлен, она запускает средство проверки файловой системы – в Linux это программа fsck, а в Windows – scandisk. Программа проверки файловой системы проверяет не что иное, а целостность файловой системы.

Когда же чистый бит не может быть установлен? Обычно тому есть две причины:

  1. Отключение питания компьютера или перезагрузка компьютера кнопкой Reset, что приравнивается к отключению питания
  2. Сбой программы (это больше касается Windows) или даже ядра (тоже больше подходит для Windows, но может случиться с любой ОС) операционной системы, что приводит к зависанию компьютера

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

Журналируемые файловые системы - ведем журнальчик

Представим такую ситуацию. У нас есть жесткий диск, скажем на 80 Гб. Сегодня таким объемом никого не удивишь, не так ли? Мы поленились разбить его на разделы и у нас есть один большой раздел на 80 Гб. В момент записи на диск произошло отключение питания. При загрузке операционная система запустит средство проверки диска. Представляешь, сколько времени займет такая проверка? Даже при условии, что ошибок будет мало или вообще не будет, придется ждать довольно долго. А если еще будет нарушена целостность, тогда восстановление этой целостности займет еще несколько минут вашего времени. Все это справедливо для обычной файловой системы. А как же работает журналируемая файловая система? Если обычная файловая система просто выполняет запланированные команды, то журналируемая система перед тем, как что-то сделать записывает стратегический план действий, например, скопировать файл file.txt в файл report.txt, а затем удалить файл file.txt. Записывается этот план в специальный файл, который называется журналом. Как только журналируемая файловая система убедиться, что пункт ее плана полностью выполнен и данные успешно записаны на диск, она вычеркивает этот пункт из журнала. Если что-то она выполнить не успела, например, ты отключил питание, при следующем запуске программа проверки файловой системы будет проверять не все данные на диске, а только те файлы, которые есть в журнале - ведь остальные данные не причем, а ошибки если и будут, то в файлах, которые записаться не успели. Почему ошибок может и не быть? Обрати внимание, что запись в журнал ведется ДО начала самой операции по работе с диском. Операция, записанная в журнал, может еще и не начаться, а питание уже пропадет. Благодаря этому даже вероятность ошибок в файловой системе значительно снижается, хотя… Лучшее средство от отключения питания – это ИБП (UPS) – пока лучше никто не придумал.

Другими словами, журналируемая файловая система – это файловая система, устойчивая к сбоям.

Основными журналируемыми файловыми системами являются:

  1. Ext3 – файловая система, пришедшая на смену стандартной файловой системы Linux – ext2
  2. XFS - разработка компании Silicon Graphics
  3. ReiserFS
  4. JFS - разработка компании IBM

Мы сначала поговорим о файловых системах XFS, ReiserFS и JFS, а о файловой системе ext3 поговорим в последнюю очередь, поскольку она заслуживает особого внимания в силу того, что она теперь является стандартной файловой системой Linux.

Файловая система XFS

Первая версия файловой системы XFS была выпущена компанией Silicon Graphics (SGI) 1 мая 2001 года. XFS была разработана для операционной системы IRIX 5.3 SGI Unix. Особенностями данной файловой системы являются:

  1. Поддержка очень больших дисков
  2. Высокая скорость ввода/вывода (до 7 Гб/с)

Использование данной файловой системы имеет смысл, если вы работаете с видео в реальном времени.

При использовании XFS вы можете установить размер блока от 512 байтов до 64 Кб. Как правило, если у тебя много маленьких файлов, устанавливается наименьший размер блока. Так можно сэкономить дисковое пространство. Если тебе приходится работать с файлами больших размеров (с тем же видео), целесообразно установить наибольший размер блока – так повысится производительность и уменьшится фрагментация.

Файловая система ReiserFS

Основной особенностью ReiserFS является способность хранить несколько мелких файлов в одном блоке. Данная особенность называется Tail Packing. Tail (хвост) – это небольшие файлы, размер которых меньше логического блока, или «остатки» более крупных файлов. Размер блока этой файловой системы фиксирован и составляет 4 Кб. В силу этого, данную файловую систему нужно использовать, если у тебя много небольших файлов, поскольку маленький размер блока негативно влияет на скорость операций ввода/вывода с большими файлами. И еще: если файловая система ReiserFS сильно фрагментирована, работать она будет очень медленно. Относительно защиты от сбоев, ReiserFS тоже слаба: в случае сбоя (например, выключения питания) данные, находившиеся в используемых во время сбоя блоках, могут быть повреждены. ReiserFS не гарантирует сохранность данных во время сбоя.

Файловая система JFS

Файловая система JFS была разработана компанией IBM для операционной системы AIX 3.1, позднее была перенесена на OS/2, а не так давно и под Linux. Размер журнала составляет примерно 40% от размера файловой системы. Максимальный размер равен 32 мегабайтам. Эта файловая система может содержать несколько сегментов, содержащих журнал и данные. Эти сегменты называются агрегатами и могут монтироваться отдельно. Основные особенности JFS:

  1. Довольно большая производительность (даже несколько больше, чем у XFS)
  2. Надежность (еще бы - ведь она же разрабатывалась для серверов!)

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

Что же касается размера блоков, то вы можете выбрать любой из четырех стандартных размеров блоков в зависимости от ваших потребностей: 512, 1024, 2048 и 4096 байт. Конечно, 4 Кб – это не 64 Кб, как в случае с XFS, и для работы с видео будет маловато, но ведь серверы практически никогда не используются для обработки видео, а данная файловая система разрабатывалась именно для серверов.

Файловая система ext3

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

В большинстве случаев файловая система ext3 устанавливается по умолчанию при установке Linux. Если ты не выбрал тип файловой системы ext3 при создании файловой системы Linux (при установке ОС), то перейти на ext3 можно с помощью команды:

/sbin/tune2fs -j <имя-раздела >

Не бойся: данная команда не переформатирует раздел, поэтому все данные останутся в целости и сохранности. Не нужно даже делать резервное копирования данных (хотя можно это сделать – на всякий случай). Опция –j как раз и указывает на то, что мы должны создать журнал файловой системы ext3. С другими опциями программы tune2fs можно ознакомиться, введя команду man tune2fs.

Команду tune2fs желательно вводить в режиме singe user mode, особенно, если мы хотим преобразовать тип корневой файловой системы. Для перехода в этот режим используется параметр single ядра Linux при загрузке операционной системы. После преобразования файловой системы нужно изменить ее тип в файле /etc/fstab на ext3. Например, если мы преобразуем тип раздела /dev/hda1, и его запись выглядела до преобразования в файле fstab так:

/dev/hda1 / ext2 defaults 1 1

то после преобразования нужно изменить ее следующим образом:

/dev/hda1 / ext3 defaults 1 0

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

Как будем вести журнал?

При работе с файловой системой ext3 можно выбрать один из режимов журнала:

  1. Журнал (Journal)
  2. Последовательный (Ordered)
  3. Обратная запись (Writeback)

Режим «Журнал» позволяет минимизировать потери при отключении питания, но является наиболее медленным из всех трех режимов. Данный режим и подразумевает запись всех изменений метаданных файловой системы, а также информации о других изменения файловой, системы в журнале.

В более быстром режиме «Последовательный» производится запись в журнал только сведений об изменении метаданных, причем запись в журнал производится перед изменением самих метаданных. Данный режим установлен по умолчанию. Самый быстрый режим – это «Обратная запись». В этом режиме записываются в журнал только сведения об имениях в файлах данных.

Какой режим выбрать? Если твой сервер является файловым (FTP, WWW-сервер), то есть таким, который используется пользователями для хранения файлов, выбери режим «Журнал» - пользователи будут благодарны. Пусть в этом режиме сервер будет работать чуть медленнее, зато в случае ЧП можно минимизировать потери информации. Во всех остальных случаях нужно установить режим «Последовательный», точнее вообще не нужно ничего устанавливать – он используется по умолчанию. Последний режим не нужно использовать – зачем тогда использовать ext3??? Для установки нужного режима используется параметр data файла /etc/fstab:

Листинг 1. /etc/fstab

# Режим Ordered. Можно явно не указывать, поскольку используется по умолчанию
/dev/hda1 / ext3 data=ordered 1 0
# Режим Journal для домашнего каталога пользователей
/dev/hda2 /home ext3 data=journal 1 0
# На этом разделе нет ничего важного – режим writeback
/dev/hda3 /opt ext3 data=writeback 1 0

После изменения файла fstab нужно заново смонтировать файловые системы или, по примеру Microsoft, перезагрузить весь компьютер.

Кто быстрее?

Тестировать производительность расматриваемых файловых систем сам не стал - в Сети очень много уже проведенных тестов, нужно только найти подходящий. Как раз только установил панель поиска Google Toolbar и выпала возможность испытать ее. Ввожу Ext2, Ext3, ReiserFS, XFS and JFS benchmarks, на что Google вернул довольно много ссылок, одна из них - http://oregonstate.edu/~kveton/fs/page1.php. На этой страничке описывается тестирование файловых систем ext2, ext3 (во всех ее режимах журнала), JFS и ReiserFS в разных режимах для больших и маленьких файлов. Жалко что тестировалось все на ядрах 2.4 и 2.5, а не 2.4 и 2.6, поэтому комментировать буду только ядро 2.4 (2.5 установлено далеко не у всех).


Сравнение производительность файловых систем при работе с большими файлами

Ориентироваться будем на загрузку CPU - ведь это решающий фактор при определении быстродействия системы - чем выше загрузка CPU тем веротянее система будет "тормозить". Минимальная нагрузка на процессор производится файловой системой ext2 (13%), но так как она не журналируемая, то ее к особому вниманию не принимаем. Среди журналируемых файловых систем лидер по самой низкой загрузке CPU - 14% - файловая система JFS. Да, забыл сказать, что смотреть нужно последовательный блочный вывод (Sequential Output, Block). При минимальной загрузке процессора JFS еще и достаточно быстра - 47178 K/sec. По быстродействию в этом режиме она - лидер (ext2 мы договорились не считать). На втором месте по быстродействию - ReiserFS - 46640 K/s, также эта файловая система на втором месте и по загрузке процессора - 24%. Файловой системе ext3 досталось третье место. Но не спешите делать выводы - мы ведь рассмотрели только последовательный блочный вывод, но ведь работа файловой системе ним не ограничивается - есть еще и другие режимы.


Скорость последовательного блочного ввода, K/sec для больших файлов

К сожалению, размер статьи не позволяет прокомментировать все режимы, поэтому сразу перейдем к маленьким файлам. Также будем рассматривать последовательный блочный ввод. По загрузке процессора и по производительности - картина та же: на первом месте jfs, затем ReiserFS, потом - ext3.


Сравнение производительность файловых систем при работе с маленькими файлами

Не могу удержаться, чтобы не прокомментировать результаты для ядра 2.5.65 - это уже почти 2.6. Для работы с большими файлами я бы выбрал JFS. По производительности она - лидер 49510 К/sec, а по загрузке процессора не сильно отличается от XFS и все той же ext2 - 14% против 13%. При работе с маленькими файлами опять лидер JFS: 49343 K/sec и 14% против 46727 K/sec и 13% у XFS. Осталось добавить, что тестирование проводилось с помощью Bonnie++. Скорее всего, другие программы покажут другие результаты. Дополнительные условия и конфигурацию тестируемой системы вы можете узнать по адресу http://oregonstate.edu/~kveton/fs/page1.php


Скорость последовательного блочного ввода, K/sec для маленьких файлов