Работа с файловой системой linux » bloglinux.ru - про свободное программное обеспечение

Дизайн

ReiserFS сохраняет файл метаданные ( «стат элементы»), каталог записи ( «пункты каталога»), инод списки блоков ( «косвенные пункты»), и хвосты файлов ( «прямые ЗАПИСИ») в одном сочетании B + дереве шпоночных по а универсальный идентификатор объекта. Блоки диска, выделенные узлам дерева, являются «форматированными внутренними блоками». Блоки для конечных узлов (в которых элементы упакованы непрерывно) являются «форматированными конечными блоками». Все остальные блоки представляют собой «неформатированные блоки», содержащие содержимое файла. Элементы каталога со слишком большим количеством записей или косвенные элементы, которые слишком длинные для размещения в узле, переходят в правого соседнего листа. Распределение блоков отслеживается по битовым картам свободного пространства в фиксированных местах.

Напротив, ext2 и другие файловые системы, подобные FFS Беркли того времени, просто использовали фиксированную формулу для вычисления местоположения inode, тем самым ограничивая количество файлов, которые они могут содержать. Большинство таких файловых систем также хранят каталоги в виде простых списков записей, что позволяет выполнять поиск в каталогах и обновлять операции с и снижает производительность в очень больших каталогах. Единое дерево B + в ReiserFS позволяет избежать обеих этих проблем благодаря лучшим свойствам масштабируемости.

16.4 Как сделать, чтобы русские имена файлов, записанные xcdroast/k3b правильно читались на MS Windows?

В xcdroast кодировка указывается в «Скомпоновать дорожки->Параметры ISO9660 закладка Входная кодировка». Выходную оставьте по умолчанию (default). Если при указании кодировки все равно русских букв в MS Windows не видно, (например, в RedHat 9 без обновлений), попробуйте обновить свой mkisofs.

В K3B такой проблемы при правильно настроенной локали не возникает. Но нужно при выставлении настроек записи отметить в закладке «Файловая система» галочки «Создать расширение RockRidge» и «Создать расширение Joliet», после чего нажать кнопку «Сохранить настройки пользователя» — тогда вам не придется делать это каждый раз.

Примечание: оригинальная версия mkisofs не понимаю UTF-8. Стоит приложить вот такой патч —
http://cvs.fedora.redhat.com/viewcvs/devel/cdrtools/mkisofs-iconv-10.patch?rev=1.1&view=log.

Что такое XFS?

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

Один из основных недостатков XFS состоит в том, что ее нельзя уменьшить. Кроме того, операции с метаданными работают немного медленнее, чем в других файловых системах, поэтому обработка большого количества небольших файлов будет значительно медленнее. Файловая система достаточно стабильна и имеет собственные инструменты для восстановления в случае необходимости. Дальше мы рассмотрим как создать эту файловую систему на вашем жестком диске и как выполняется настройка XFS.

16.23 Есть раздел под NTFS, как мне его увидеть из-под Linux? Как сделать видимыми русские буквы на NTFS? Могу ли я писать на NTFS?

Прописываем в /etc/fstab строчку вроде

для локали koi8-r:

/dev/hda1 /mnt/disk_c ntfs dmask=0,fmask=0111,iocharset=utf-8,ro 0 0

/dev/hda1 /mnt/disk_c ntfs dmask=0,fmask=0111,utf8,ro 0 0

где /dev/hda1 — название вашего диска, а /mnt/disk_c — каталог, который вы под него создали. В новых ядрах вместо «iocharset=…» лучше использовать «nls=…».

В ядрах дистрибутивов RedHat по умолчанию поддержка NTFS не собирается. Поэтому нужно зайти в любой
и скачать пакет с поддержкой под свое ядро или
.

Как записывать на NTFS? Начнем с того, что это опасно и вы можете повредить свои данные на NTFS. Не говорите, что не предупреждал. Существует три способа:

Собрать ядро с поддержкой записи на NTFS. На ядрах 2.4.x запись возможна только на NTFS от NT4.0, на ядрах 2.6 на любой NTFS. Однако есть три ограничения: Вы можете писать в уже созданный файл (т.е. изменять его). Вы не сможете создать новый файл! Вы не можете изменять его размер!
Купить (или найти в какой-нибудь p2p сети) ‘Paragon NTFS driver for linux’. Сайт компании:
http://www.ntfs-linux.com Наилучший способ. Стоит все удовольствие $70. Одна маленькая неприятность — не работает с ядрами серии 2.6.х
Использовать продукт обратной разработки под названием captive. Позволяет читать и писать на NTFS. Недостаток: он медленно пишет и ему нужна пара файлов из MS Windows (причем один из них — драйвер NTFS).
http://www.jankratochvil.net/project/captive

А здесь можно почитать о состоянии поддержи NTFS на текущий момент —
http://linux-ntfs.sourceforge.net/info/ntfs.html

Русское FAQ с этого сайта лежит
здесь (внимание, оно довольно старое).

Reiser4

Reiser4 совершенно новый, и его не следует путать со старым ReiserFS. Поэтому он не продается как «ReiserFS 4». Используется модификация структуры дерева B * , так называемые танцующие деревья . Основное отличие состоит в том, что недостаточно заполненные узлы объединяются не при каждой модификации дерева, а только тогда, когда требуется обратная запись в постоянное хранилище из-за нехватки памяти или завершения транзакции.

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

Кроме того, была добавлена гибкая структура подключаемых модулей , с помощью которой можно реализовать специальные типы метаданных , шифрование и сжатие . В Reiser4 метаданные файла, такие как название и исполнитель музыкального файла, могут храниться в файловой системе, а не в приложениях. Отличие, например, от тегов ID3 из файлов MP3 и сопоставимых систем метаданных состоит в том, что система метаданных интегрирована в файловую систему, а не в формат контейнера файла, который может быть одинаковым для всех файлов. Если бы этот подход когда-либо был реализован, не было бы необходимости беспокоиться о том, понимает ли приложение все типы метаданных, с которыми оно может контактировать. Он мог получить доступ к метаданным прозрачно через функцию файловой системы. Хотя это может улучшить совместимость приложений, это затрудняет совместимость файловой системы, поскольку метаданные не могут быть скопированы в другую файловую систему без этой системы метаданных, такой как ext4 , XFS или FAT32 . Также NTFS поддерживает такие альтернативные потоки .

Работа с ReiserFS

Инсталляция tools.

До перезагрузки следует инсталлировать «reiserfsprogs» tools, которые состоят из «mkreiserfs», «resize_reiserfs» (полезно,
если у вас используется LVM) и «fsck.reiserfs». Получить самую последнюю версию «reiserfsprogs» (на момент написания статьи —
«3.x.0j») можно от Namesys.com download page. Как только tools загружены, их можно
компилировать и инсталлировать следующими командами:

После инсталляции tools можно создавать новые partitions (используя «fdisk» или «cfdisk») либо LVM logical volumes
(используя «lvcreate») по необходимости и перезагрузить систему. Когда создается standard partitions его можно маркировать
как «Linux native file system» (83).

Создание и монтирование файловой системы.

После перезагрузки вы сможете создать файловую систему ReiserFS на пустом partition следующей командой:

В этом примере /dev/hdxy — device node, соответствующий свободному partition. Монтирование аналогично любой другой
файловой системе:

Добавить файловую систему ReiserFS в файл /etc/fstab можно при установке полей «freq» и «passno» в значение «0»,
например:

Начиная с этого момента ваша ReiserFS внешне становится тождественной ext2. Вы быстро забудете об изнурительном «fsck»,
а данные станут доступны быстрее, особенно из маленьких файлов.

Дизайн

inode

inode, индексный дескриптор — это структура данных в традиционных для ОС UNIX файловых системах. В этой структуре хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имени.

Каждый файл имеет свой индексный дескриптор, идентифицируемый по уникальному номеру (часто называемому i-номером или инодом) в файловой системе, в которой располагается сам файл.

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

Атрибуты

длина файла в байтах;
идентификатор (ID) устройства (это идентифицирует устройство, содержащее файл);
ID пользователя, являющегося владельцем файла;
ID группы файла;
режим файла, определяющий какие пользователи могут считывать, записывать и запускать файл;
Timestamp указывает дату последнего изменения инода (ctime, change time), последней модификации содержимого файла (mtime, modification time), и последнего доступа (atime, access time);
счетчик ссылок указывают количество жестких ссылок, указывающих на индексный дескриптор;
указатели на блоки диска, хранящие содержимое файла.

Особенности

Файловые системы, использующие индексные дескрипторы, имеют несколько неочевидных особенностей:

Если несколько имен указывают на один и тот же индексный дескриптор (жёсткие ссылки), то все имена считаются эквивалентными. Первое созданное имя никаким особым положением не обладает. Это отличается от поведения похожих символьных ссылок, которые зависят от первоначального имени.
Индексный дескриптор может совсем не иметь ссылок. Обычно такой файл должен быть удален с диска (именно поэтому программы типа undelete в Unix не позволяют установить точное имя удалённого файла), а его ресурсы должны освободиться (это нормальный процесс удаления файла), но если какие-либо процессы ещё не закрыли файл, то они могут удерживать доступ к нему, а файл будет окончательно удален только после того, как будет закрыто последнее обращение к нему. Это относится и к исполняемым копиям, которые удерживаются открытыми процессами, их выполняющими. По этой причине при обновлении программы рекомендуется удалять старую копию и создавать новый индексный дескриптор для обновленной версии, чтобы никакие экземпляры старой версии не продолжали выполняться.
Обычно нет возможности сопоставить открытый файл и его имя, по которому он был открыт. Операционная система преобразует имя файла в номер индексного дескриптора при первом же удобном случае, а затем «забывает» про использованное имя файла. Таким образом, функции библиотек getcwd() и getwd() начинают искать в родительском каталоге файл с индексным дескриптором, совпадающим с файлом «.» каталога; затем ищут родительский каталог для текущего, и так далее пока не достигнут «/» каталога. SVR4 и Linux используют дополнительную информацию (поля) в индексных дескрипторах для избежания подобного неудобства.
Ранее было возможно применять жёсткие ссылки на каталоги. Это делало структуру каталогов ориентированным графом вместо дерева (то есть связного графа с N-1 ребрами и N узлами). Например, каталог имел возможность быть собственным родителем. Современные файловые системы не допускают подобных двусмысленностей, за исключением корневого каталога, который считается собственным родителем.
Номер индексного дескриптора файла остается неизменным при перемещении файла в другой каталог на том же устройстве или при дефрагментации диска. Поэтому перемещения или каталога, содержащего файл, или его содержимого (или и того и другого вместе) недостаточно для предотвращения доступа к нему из уже запущенного процесса, если у процесса есть возможность вычислить номер индексного дескриптора. Это также обусловливает то, что полностью управляемое поведение индексных дескрипторов невозможно реализовать на множестве файловых систем, не произошедших от стандартной файловой системы UNIX, таких как FAT и его преемников, которые не имеют возможности хранить подобную постоянную ‘неизменность’, когда каталог файла и его содержимое перемещается.

использование

ReiserFS была файловой системой по умолчанию в SuSE Linux с версии 6.4 (выпущенной в 2000 году) до перехода на ext3 в SUSE Linux Enterprise 10.2 и openSUSE 11, объявленного в 2006 году.

Джефф Махони из SUSE написал сообщение 14 сентября 2006 г., в котором предлагалось перейти с ReiserFS на ext3 в качестве файловой системы установки по умолчанию. Среди причин, которые он назвал, были масштабируемость, «проблемы с производительностью с расширенными атрибутами и списками контроля доступа », «небольшое и сокращающееся сообщество разработчиков» и то, что « Reiser4 не является инкрементным обновлением и требует переформатирования, что для большинства людей неразумно». 4 октября он написал ответный комментарий в блоге, чтобы прояснить некоторые проблемы. Он написал, что его предложение о переходе не связано с тем, что Ханса Райзера судят за убийство. Махони писал, что он «был обеспокоен тем, что люди установят связь там, где ее не было», и что «время полностью случайно, а мотивация не связана».

Принцип работы [ править | править код ]

Журналируемая файловая система сохраняет список изменений, которые она будет проводить с файловой системой, перед фактическим их осуществлением. Эти записи хранятся в отдельной части файловой системы, называемой журналом (англ. journal ) или логом (англ. log ). Как только изменения файловой системы внесены в журнал, она применяет эти изменения к файлам или метаданным, а затем удаляет эти записи из журнала. Записи журнала организованы в наборы связанных изменений файловой системы.

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

По типу внесения в журнал журналируемые ФС подразделяются на:

в режиме обратной связи (журналируются только метаданные): XFS, ext3;
упорядоченные (журналируются только метаданные синхронно относительно данных): JFS2, ext3 (по умолчанию), ReiserFS (основной);
в режиме данных (журналируются как метаданные, так и данные): ext3;

использование

Джефф Махони из SUSE написал сообщение 14 сентября 2006 г., в котором предлагалось перейти с ReiserFS на ext3 в качестве файловой системы установки по умолчанию. Некоторыми причинами, которые он назвал, были масштабируемость, «проблемы с производительностью с расширенными атрибутами и ACL », «небольшое и сокращающееся сообщество разработчиков» и что « Reiser4 не является инкрементным обновлением и требует переформатирования, что для большинства людей неразумно. » 4 октября он написал ответный комментарий в блоге, чтобы прояснить некоторые проблемы. Он написал, что его предложение о переходе не было связано с тем, что Ханс Райзер предстал перед судом за убийство. [ не удалось проверить] Махони писал, что он «был обеспокоен тем, что люди установят связь там, где ее не было», и что «время полностью случайно, а мотивация не связана».

The ac9 patch and bigpatch

Можно использовать простое 2.4.4 ядро, в нем все имеется. Однако я рекомендую применить следующие ac и bigpatch patches.

Для apply the ac9 patch, получите
Alan Cox ac9 patch из kernel.org и выполните:

# cd /usr/src/linux
# bzip2 -dc /path/to/patch-2.4.4-ac9.bz2 | patch -p1

Наложив такой patch (или оставив все без изменений), получите
DiCE и ReiserFS bigpatch. Опять
же, этот шаг необязателен, но мною рекомендованный, особенно для NFS сервера и поддержки квот (даже если это вам не нужно,
patch не навредит). Для наложения bigpatch выполните:

# cd /usr/src/linux
# bzip2 -dc /path/to/bigpatch-2.4.4.diff.bz2 | patch -p1

Выполнив один, оба или ни одного шага, вы готовы к конфигурированию ядра для ReiserFS.

Обратите внимание: если вам требуется помощь в компиляции ядра, есть хорошая, свободно распространяемая обучающая
программа
Compiling the Linux kernel на developerWorks. Далее очень кратко

Конфигурирование ядра весьма просто. Сначала выполняем «make menuconfig». В секции «Code maturity level
options» убедитесь, что опция «Prompt for development and/or incomplete code/drivers» — enabled. Переходим
в секцию «File systems» и enable «ReiserFS support». Вы должны конфигурировать поддержку ReiserFS для
компилирования непосредственно в ядро, а не как модуль. Теперь не помешает разрешить «Have reiserFS do extra internal
checking». Сохраните конфигурацию и компилируйте ядро («make dep; make bzImage; make modules; make modules_install») и
добавьте запись в ваш загрузчик для ReiserFS-enabled kernel.

Важно: никогда не удаляйте ваше текущее ядро, не убедившись в работоспособности нового

16.15 Как перекодировать русские названия файлов в транслит?

Способ первый, хороший:

#!/bin/sh
# Перекодирует рекурсивно в текущем
каталоге имена # файлов и каталогов в
транслит.

shopt -s nullglob
for NAME in *
do
TRS=`echo $NAME | tr абвгдезийклмнопрстуфхцы abvgdezijklmnoprstufxcy` TRS=`echo $TRS | tr АБВГДЕЗИЙКЛМНОПРСТУФХЦЫ ABVGDEZIJKLMNOPRSTUFXCY` TRS=${TRS//ч/ch}; TRS=${TRS//Ч/CH} TRS=${TRS//ш/sh}; TRS=${TRS//Ш/SH} TRS=${TRS//ё/jo}; TRS=${TRS//Ё/JO} TRS=${TRS//ж/zh}; TRS=${TRS//Ж/ZH} TRS=${TRS//щ/sh\'}; TRS=${TRS//Щ/SH\'} TRS=${TRS//э/je}; TRS=${TRS//Э/JE} TRS=${TRS//ю/ju}; TRS=${TRS//Ю/JU} TRS=${TRS//я/ja}; TRS=${TRS//Я/JA} TRS=${TRS//ъ/\`}; TRS=${TRS//ъ\`} TRS=${TRS//ь/\'}; TRS=${TRS//Ь/\'} if ]; then
  mv -v "$NAME" "$TRS"
  cd "$TRS"
  "$0"
  cd ..
else
  mv -v "$NAME" "$TRS"
fi
done

За скрипт благодарим Гирченко Валерия (Valerius)

Способ второй, сложный. Оставлен на всякий случай.
Нужна программа translit и 2 нижеуказанных скрипта.
http://rpm.pbone.net/index.php3/stat/4/idpl/423272/com/translit-1.03-1.i386.rpm.html

$ cat tr-walker.sh
----------------------------------------
#!/bin/bash
TPWD=`pwd`

`/usr/local/bin/mp3-translit.pl`;

for f in *; do
    cd "$TPWD/$f";
    TTPWD=`pwd`
    echo "Converting: $TTPWD";
    `/usr/local/bin/mp3-translit.pl`;
    cd "$TPWD";
done

$ cat mp3-translit.pl
--------------------------------------
#!/usr/bin/perl -w

use strict;

use File::Copy;

my $dirName=$ARGV;
$dirName ||='.';
my $file='';
my $cnt=0;
opendir(DIR, "$dirName") or die "Can't opendir $dirName: $!";
while (defined($file=readdir(DIR))) {
    next if $file=~/^\.\.?$/;
    my $trFile=getTRname($file);
    if (-f $file) { `chmod 0644 "$file"` };
    if (-d $file) { `chmod 0755 "$file"` };
    move("$dirName/$file","$dirName/$trFile");
}

closedir(DIR);

sub getTRname {
    my $input=$_;
    my $trFile=`echo "$input" | iconv -f UTF-8 -t KOI8-R  | translit koi8-phg.rus`;
    $trFile=~s///gs;
    $trFile=~s/\.+/\./g;
    $trFile=~s/\ /_/g;
    $trFile=~s/\_+/\_/g;
    $trFile=~s/\-+/\-/g;
    return $trFile;
}

Разновидности журналирования

Еще материалы developerWorks из серии от Тима Джонса

Анатомия файловых систем Linux для флеш-памяти (EN)
Анатомия Linux с улучшенной безопасностью (Security-Enhanced Linux, SELinux)
Анатомия архитектур реального времени для Linux (EN)
Анатомия подсистемы SCSI в Linux
Анатомия файловых систем Linux
Анатомия сетевого стека в Linux
Анатомия ядра Linux
Анатомия распределителя памяти slab в Linux
Анатомия методов синхронизации Linux
Все статьи Тима серии Анатомия.(EN)
Все статьи Тима на developerWorks(EN)

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

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

Правила применения изменений, зафиксированных в журнале, также могут быть разными в разных подходах. Например, когда следует применять изменения? Когда журнал полон? Или когда истекает некий таймаут?

Типы файловых систем Linux — описание и обзор

Файловые системы условно делятся на два типа

Журналируемые. Имеют в своем арсенале специальный файл, который хранит историю действий (лог) и план дальнейшей проверки. Характерной особенностью является устойчивость к сбоям и большая гарантия на сохранение целостности данных.
Не журналируемые. Отсутствует файла с логом. Работают более быстро. Не гарантируют целостность и сохранность данных. Особенно это проблема встает в случае сбоев, когда некоторые действия могли редактировать файл и прервать изменения в неправильном месте.

Узнать файловую систему в ОС Linux

file -s

Самые популярными типами ФС в Linux являются:

Ext4 (считается стандартом для Linux)
Ext2
ReiserFS
XFS
SWAP

В Windows поддерживаются свои ФС: NTFS, FAT32. Линукс также их поддерживает, а вот Windows не поддерживает линуксовые системы.

1 Extfs (Extended File System). Дата появления на свет апреле 1992 года. Самая первая файловая система разработанная специально для ОС на ядре Linux. Наибольший возможный размер раздела файла — 2 Гб. Максимальная длина имени файла — 255 символов. Является прародителем популярных ФС Ext2, Ext3.

2 Ext2 (second extended file system). Дата создания 1993 год. Является не журналируемой файловой системой. Была популярна до 2000-х. Имеет ряд ограничений на работу с большими файлами, зато является и самой быстрой, поэтому её часто используют в различных сравнительных тестах как эталонную.

3 Ext3 (third extended filesystem). Дата выхода 2001 год. Считается революционной, поскольку относится к поколению журналируемых систем. В настоящее время файловая система Ext3 поддерживает файлы размером до 1 ТБайт. Используется в некоторых случаях до сих пор. Разделы Ext3 могут читать Windows-программы (например, Total Commander). Разработчик Стивен Твид.

4 Ext4 (дата выхода 2006 год). Является стандартом во всех современных Linux (а сейчас 2019 год). Хорошо защищена от проблем фрагментации и оптимизирована для работы с большими файлами. Максимальный размер файловой системы не может превышать 16 ТБайт.

5 ReiserFS (или Reiser3). Создана уже после ext3 в качестве ее альтернативы. Журналируемая система. Поддерживает большую производительность. Позволяет изменять размеры разделов во время работы.

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

6 Reiser4 (дата создания 2004 году). Система включает себя такие передовые технологии как транзакции, задержка выделения пространства, а так же встроенная возможность кодирования и сжатия данных.

7 XFS (журналируемая файловая система). Это производительная файловая система, разработанная в Silicon Graphics для свой операционной системы еще в 2001 году. Позволяла использовать диски 2 ТБайт. Существует возможность потери данных во время записи при сбое питания, так как большое количество буферов хранится в памяти.

8 Btrfs или B-Tree File System. Журналируемая файловая система. Совершенно новоиспеченная файловая система, которая сосредоточена на отказоустойчивости, свободности администрирования и восстановления данных. К её особенностям относятся хранение индекса файлов в так называемых «B-деревьях» – иерархических структурах, которые максимально оптимально используют ресурсы оперативной памяти за счёт небольшой глубины вложения данных.

9 SWAP – особый вид не журналируемой файловой системы, которая реализует структуру хранения данных, аналогичную структуре оперативной памяти. Используется для реализации файла подкачки в Linux.

Пример: восстановление удалённого незакрытого файла

sobols@sobols-VirtualBox:~/20161215/undelete$ less hello.txt &

sobols@sobols-VirtualBox:~/20161215/undelete$ rm hello.txt 

sobols@sobols-VirtualBox:~/20161215/undelete$ pgrep less
4404

sobols@sobols-VirtualBox:~/20161215/undelete$ lsof -p 4404
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
less    4404 sobols  cwd    DIR    8,1     4096 283261 /home/sobols/20161215/undelete
less    4404 sobols  rtd    DIR    8,1     4096      2 /
less    4404 sobols  txt    REG    8,1   169800 262220 /bin/less
...
less    4404 sobols    4r   REG    8,1    35711 283262 /home/sobols/20161215/undelete/hello.txt (deleted)

sobols@sobols-VirtualBox:~/20161215/undelete$ ls /proc/4404/fd/ -l
total 0
lrwx------ 1 sobols sobols 64 Снж 15 02:26 0 -> /dev/pts/0
lrwx------ 1 sobols sobols 64 Снж 15 02:26 1 -> /dev/pts/0
lrwx------ 1 sobols sobols 64 Снж 15 02:26 2 -> /dev/pts/0
lr-x------ 1 sobols sobols 64 Снж 15 02:26 3 -> /dev/tty
lr-x------ 1 sobols sobols 64 Снж 15 02:26 4 -> /home/sobols/20161215/undelete/hello.txt (deleted)

sobols@sobols-VirtualBox:~/20161215/undelete$ cp /proc/4404/fd/4 hello2.txt

Приемы повышения производительности

К счастью, имеется пара простых приемов, которые вы можете использовать для «купирования» проблем производительности.
Первый прием — монтирование ReiserFS с опцией «noatime» (опция монтирования, доступная и для других файловых систем).
Вероятно, вы знаете, что системы UNIX делают запись atime (время доступа) для каждого объекта файловой системы и этот атрибут
модифицируется при каждом чтении файла. Для большинства случаев штамп atime интереса не представляет (даже не могу привести
пример, когда atime требуется для «критических» приложений). По этой причине, ничем не рискуя, от его модификации можно
отказаться и получить выигрыш в производительности. Можно даже сказать следующее. Если вам не известно, что штамп atime
требуется для конкретного приложения, разместившего файлы на конкретной файловой системе, то вы должны монтировать ее с опцией
noatime. Используйте примерно следующую запись в /etc/fstab:

/dev/hdc1       /home                   reiserfs        noatime       0 0

В первой статье о ReiserFS я упомянул, что ReiserFS имеет специфическую feature, называемую
«tail packing» (упаковка хвостов). А что в ReiserFS называют «хвостами»? Во-первых, файлы, размер которых меньше, чем блок
файловой системы или, во-вторых, «кончики» файлов, которые не заполняют весь блок. В первом случае ReiserFS имеет превосходную
производительность по причине умения «запихивать» такие «карликовые» файлы в свои b*tree (первичная организационная структура
данных). При этом данные хранятся рядом со stat-data (ReiserFS эквивалент i-node). Во втором случае с производительностью иначе.
Хвосты не заполняют полный блок и непроизводительно используют дисковое пространство. Для лучшего использования дискового
пространства ReiserFS использует «tail packing». Считается, что такая feature позволяет экономить более 5% в сравнении с ext2.

Технические примечания по ReiserFS.

Стабильность файловой системы.

Я использовал 2.4.4 с ReiserFS на промышленном сервере в течение месяца (на cvs.gentoo.org development сервере) без
каких-либо проблем. 2.4.4 и 2.4.4-ac9 зарекомендовали себя надежными. Сервер сильно загружен операциями IO, так как на нем
хранятся cvs архив нашего «dev-wiki», почтовый сервер gentoo.org, списки рассылки
и другое.

Ограничения ReiserFS.

Хотя ReiserFS превосходит по быстродействию практически во всех типах приложений «файловую классику» ext2, имеется ряд
областей, где ReiserFS в настоящее время еще не доработан. Это не жесткие ограничения ReiserFS, а те области, до которых
разработчики Namesys не имели время добраться.

Отсутствие dump/restore

Да, это истина. ReiserFS не имеет «dump» и «restore» реализации. Если вы желаете использовать ReiserFS, но вам нравится
«dump», придется находить иные пути бэкапу данных. В действительности это не так актуально. Ядро 2.4 несовместимо с «dump» и
«restore» в принципе (а не только на ReiserFS). Для подробной информации о dump/kernel 2.4 incompatibility читайте Linus
Torvalds, где он говорит, «Dump была глупой программой, во-первых.
Оставьте ее в прошлом.»

Проблемы производительности.

Хотя ReiserFS в общем, имеет преимущество в производительности над ext2, в частностях имеются и слабости. Первая — работа
с «разреженными» файлами (например, mailbox). ReiserFS заметно хуже справляется с разреженными файлами, чем ext2. Положение
должно изменится, когда разработчики Namesys вернуться к оптимизации этой стороны ReiserFS (предполагается в версии 4 ReiserFS).
А сейчас ext2 — лучшее решение для приложений, которые помещают информацию в разреженные файлы.

Заключение.

Я нахожу, что ReiserFS очень приятная файловая система и дает выигрыш не только на маленьких, но и на больших файлах по
сравнению с ext2. Благодаря ReiserFS разработчикам требуется только 15 секунд для модификации CVS Gentoo Linux, притом, что на
ext2 это занимало около 2 минут. ReiserFS делает работу более комфортной и позволяет нашему cvs серверу одновременно
обрабатывать большее число IO без потери интерактивности.

Притом, что она уже сегодня производит впечатление, будущее представляется еще более интересным. Hans Reiser имеет очень
агрессивный творческий план относительно ReiserFS, включая использование ее как full-fledged high-performance database с полной
поддержкой transaction и advanced querying features. Со временем можно ожидать, что ReiserFS станет больше чем «другая
высокоэффективная файловая система». Это должно открыть новые возможности и подходы для решения традиционных проблем хранения
информации. С Namesys можно связывать и будущее развитие Linux.

Resources

Читайте другие статьи этой серии от Daniel Robbins:
- Презентация ReiserFS. (Часть 1)
- Использование ReiserFS в Linux 2.4. (Часть 2)
- Презентация tmpfs и bind mounts. (Часть 3)
- Презентация devfs. (Часть 4)
- Установка devfs. (Часть 5)
- Переход на devfs (с использованием init wrapper). (Часть 6)
- Презентация ext3. (Часть 7)
- Неожиданности от ext3. (Часть
- Презентация XFS. (Часть 9)
- Развертывание XFS. (Часть 10)
- Совершенствование файловых систем. (Часть 11)
Keep an eye on DiCE’s download page for the latest ReiserFS bigpatch.
The ReiserFS mailing list is an excellent source for current, more
in-depth ReiserFS information. Be sure to check out the ReiserFS mailing list archive, too.
Linux Weekly News is a great resource for keeping up with the latest kernel developments.
You can find a very nice detailed look at the meta-data differences between UFS, ext2, ReiserFS, and more in Juan I. Santos
Florido’s Journal File Systems review in Linux Gazette.
Jedi’s ReiserFS/Qmail tuning page contains a lot of good
information for qmail users. Also be sure to check out
ReiserSMTP, Jedi’s collection of drop-in qmail components that offer dramatically higher qmail performance.
Check out the mutt e-mail client, which can be used to read large maildir-style mailboxes.
Read Linus Torvalds’ recent comments on dump and restore.
Take the
Compiling the Linux kernel free tutorial on developerWorks.
Browse more Linux resources on developerWorks.
Browse more Open source resources on developerWorks.

About the author

Residing in Albuquerque, New Mexico, Daniel
Robbins is the
President/CEO of Gentoo Technologies, Inc., and the creator of Gentoo LinuxPortageCaldera OpenLinux UnleashedSuSE Linux UnleashedSamba
UnleashedSONY Electronic Publishing/Psygnosisdrobbins@gentoo.orgВладимир Холманов