С выходом релиза 2.4 Linux появилась возможность использования
filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других.
Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они
могут делать, насколько они хороши и насколько оправдано их использование в
промышленной Linux среде. В этой статье Daniel дает обзор tmpfs, файловой
системы, основанной на VM, и описывает новые, ставшими доступными с переходом
на ядро 2.4 возможностями "bind"-mounting abilities.
В предыдущих статьях этой серии я описал преимущества журналирования вообще
и файловую систему ReiserFS в частности. Была описана процедура установки
rock-solid Linux 2.4-based ReiserFS файловой системы. В данной статье обратим
свое внимание на нетривиальную тему. Сначала будет рассмотрена tmpfs, еще
известная как virtual memory (VM) filesystem. Tmpfs - вероятно лучшая
RAM disk-like система, уже сейчас доступная для Linux через новые свойства
ядра 2.4. После начального вступления рассмотрим дополнительные возможности
ядра 2.4, называемые "bind mounts", которые добавляют много гибкости в
монтировании файловых систем. В следующей статье мы сосредоточимся на devfs,
а затем потратим время на более глубокое знакомство с новой ext3 filesystem.
Если от меня потребуют объяснить в одной фразе, что такое tmpfs, я бы сказал -
tmpfs подобие ramdisk, но с "изюминкой". Подобно ramdisk, tmpfs использует
ОПЕРАТИВНУЮ ПАМЯТЬ, но, кроме этого, может использовать swap devices. В то
время как традиционный ramdisk это блочное устройство и перед его
использованием необходимо отформатировать раздел командой mkfs с опциями,
то файловая система tmpfs - устройство не блочное, готовое к использованию
сразу после монтирования. Такие свойства tmpfs делают ее самой привлекательной
из RAM-based файловых систем, известных на сегодняшний день.
Давайте посмотрим на некоторые наиболее интересные свойства tmpfs. Как было
отмечено выше, tmpfs может использовать и RAM, и swap. На первый взгляд,
это может показаться не принципиальным, но вспомните, tmpfs еще известна как
"virtual memory filesystem". Возможно, вы знаете, что ядро Linux "понимает"
ресурс "виртуальная память" именно как единое - целое RAM и swap devices.
Подсистема VM ядра ассигнует эти ресурсы другим подсистемам и управляет этими
ресурсами behind-the-scenes (прозрачно в фоне). При этом часто без ведома
"подсистемы - заказчика" перемещает страницы ОПЕРАТИВНОЙ ПАМЯТИ между swap
и vice-versa.
Файловая система tmpfs запрашивает страницы у подсистемы VM для хранения
файлов. При этом сама tmpfs не знает, находятся ли эти страницы в swap или
в RAM; это - "проблема" VM подсистемы. Иначе, tmpfs filesystem знает лишь то,
что она использует виртуальную память.
Теперь о другом интересном свойстве tmpfs filesystem. В отличие от большинства
"нормальных" файловых систем (например, ext3, ext2, XFS, JFS, ReiserFS) tmpfs
не является "надстройкой" над блочным устройством. Поскольку tmpfs напрямую
"встроена" в VM, ее можно монтировать сразу после создания командой:
# mount tmpfs /mnt/tmpfs -t tmpfs
После выполнения команды вы получите новую tmpfs filesystem, смонтированную
в /mnt/tmpfs и готовую к использованию. Обратите внимание, нет потребности в
форматировании командой mkfs tmpfs; да это и невозможно, такой
команды просто не существует. Сразу после команды mount файловая
система доступна для использования и имеет тип tmpfs. Это в
принципе отличается от Linux ramdisks; стандартный Linux ramdisks -
block devices и требует форматирования перед размещением на нем файлов.
Что имеем? Монтируй и используй!
Вы вероятно уже задавались вопросом, а какого размера файловую систему мы
подмонтировали к /mnt/tmpfs в примере выше? Ответ неожиданный (особенно, если
имели дело только с disk-based файловыми системами). /mnt/tmpfs первоначально
имеет очень маленький размер, но, по мере копирования и создания файлов
драйвер tmpfs ассигнует у VM дополнительную память, динамически увеличивая
емкость. Справедливо и обратное, при удалении файлов из /mnt/tmpfs драйвер
отдает освобождаемую память операционной системе. Теперь ясно (память
достаточно ценный ресурс и ее "никогда не бывает много"), большой плюс tmpfs
в том, что используется ровно столько памяти, сколько требуется.
См. Resources.
Другое преимущество tmpfs - ее "блестящая" скорость. Поскольку файловая
система tmpfs постоянно загружена в оперативную память, операции записи -
чтения происходят почти мгновенно. Даже если интенсивно используется swap,
скорость все равно высокая (более того, перемещение в swap означает передачу
ресурсов процессам, наиболее нуждающимся в памяти, что способствует повышению
общей производительности). Итог - свойство динамически изменять размер и,
при необходимости, сбрасываться в swap, дает возможность операционной системе
более гибко распоряжаться ресурсами. Файловая система tmpfs прекрасная
альтернатива традиционному RAM disk с позиции скорости.
А вот это может считаться как плюсом, так и минусом. Как можно догадаться,
данные в tmpfs после перезагрузки будут потеряны (оперативная память
энергозависима по своей природе. Даже после "горячей перезагрузки",
сохранившись в "физической оперативной памяти", информация станет недоступной,
так как таблицы виртуальной памяти будут инициализированы иначе). Название
"tmpfs" само за себя говорит. Плохо ли это? С какой стороны посмотреть.
Фактически, tmpfs превосходный резервуар для хранения временных файлов.
Традиционно для этих целей используется /tmp и некоторые части дерева /var.
Есть даже опция - очищать /tmp при перезагрузке, на что тратится дополнительное
время. В случае с tmpfs, такая "опция" - физическое свойство.
Все, что требуется для использования tmpfs - это ядро 2.4, скомпилированное
с "Virtual memory file system support (former shm fs)" enabled;
эта опция находится в подразделе "File systems"
(make menuconfig). Если на вашей системе такое ядро, уже можно
монтировать tmpfs filesystems. На предкомпилированных ядрах дистрибутивов это,
как правило, сделано всегда. Можно не пользоваться самой tmpfs, но такая
поддержка требуется для использования POSIX shared memory. Заметим,
для использования System V shared memory поддержка tmpfs в ядре не
требуется. POSIX shared memory широкого применения еще не получила,
но это дело времени.
А чего это мы все говорим о достоинствах? Фактом является то, что tmpfs
динамически растет и уменьшается. Поэтому естественен провокационный вопрос.
А что случится, если tmpfs filesystem разрастется так, что поглотит всю
виртуальную память? Скажем так, приемлемое решение еще не найдено.
С ядром 2.4.4, увы, произошло бы зависание. С ядром 2.4.6, подсистема VM имеет
некоторую защиту, и авария не произойдет. Когда 2.4.6 почувствует точку,
за которой ассигнование дополнительной памяти проблематично, вы просто не
сможете ничего более записать в tmpfs filesystem. Кроме того, произойдут
некоторые другие вещи. Сначала процессы в системе не смогут ассигновать
дополнительную память; внешне система станет очень вялой. У суперпользователя
есть время, чтобы предпринять шаги для выхода из low-VM condition.
Далее, ядро имеет встроенную last-ditch систему освобождения памяти при ее
исчерпании; она находит процесс, который наиболее "жадно" потребляет VM ресурсы
и уничтожает его. К сожалению, такое "kill a process" решение имеет неприятные
последствия, особенно, если в истощении памяти виновата tmpfs. Причина вот
в чем. Сама tmpfs уничтожена быть не может, так как она - часть ядра, а не
пользовательский процесс. Кроме того, специфика tmpfs такова, что для ядра не
существует простого способа выяснить, какой именно процесс "затопляет" tmpfs.
В таких случаях ядро ("вот разберусь до конца и накажу, кого попало") по
ошибке "убивает" самый большой VM-hog процесс, которым обычно является ваш
X server. Определить, что истинной причиной "падения" X было low-VM condition
(tmpfs) очень сложно.
К счастью, tmpfs позволяет указать максимальный размер filesystem при ее
монтировании или перемонтировании. Фактически, с ядром 2.4.6 и util-linux-2.11g,
такие параметры можно установить только при монтировании, но не
перемонтировании (в следующих версиях ядер это может быть уже решено).
Установка оптимального лимита на размер tmpfs зависит от ресурсов и режима
использования Linux box; идея в том, чтобы предотвратить возможность со
стороны tmpfs filesystem истощения ресурсов виртуальной памяти и предотвратить
low-VM conditions, о чем говорилось ранее. Хороший способ найти приемлемый
tmpfs upper-bound состоит в использовании top монитора для
наблюдения за swap в момент пиковых нагрузок. Установите tmpfs upper-bound
немного меньше, чем сумма свободной swap и RAM при пиковой нагрузке.
Создать tmpfs filesystem с лимитом на максимальный размер достаточно просто.
Например:
# mount tmpfs /dev/shm -t tmpfs -o size=32m
В этом примере монтирование новой tmpfs происходит не к точке /mnt/tmpfs,
а к специально созданному /dev/shm. Это каталог, который является
"official" mountpoint для tmpfs. Если вы используете devfs, этот каталог
будет создан автоматически.
Если требуется ограничить размер filesystem 512 КБ или 1 GB, можно
соответственно указать size=512k или size=1g.
В дополнение к ограничению размера можно лимитировать число inodes (filesystem
objects) через параметр nr_inodes=x. Где x - целое число,
возможно, с суффиксом k, m или g для обозначения тысяч, миллионов или
миллиардов inodes.
Для автоматического монтирования при загрузке системы допустимо сделать
запись в файле /etc/fstab. Например:
При использовании ядер 2.2 любая попытка монтирования к уже используемой
mountpoint приводила к ошибке. После переписи кода ядра повторное монтирование
к занятой точке перестало быть проблемой. Такой пример: при загрузке системы
монтируется "реальный" раздел диска к точке /tmp. Принимается оперативное
решение использовать tmpfs. В старое время потребовалось бы размонтировать /tmp
и повторно смонтировать tmpfs в /tmp:
Однако не всегда это возможно. Если есть процессы с открытыми в /tmp файлами
будет выдана следующая ошибка:
umount: /tmp: device is busy
На последних 2.4 ядрах можно перемонтировать /tmp filesystem без получения
ошибки "device is busy":
# mount tmpfs /tmp -t tmpfs -o size=64m
Единственной командой ваша новая tmpfs filesystem монтируется к /tmp поверх
ранее смонтированного partition. При этом все новые файлы будут открываться
на tmpfs, а процессы, которые имели открытые файлы на "оригинальной"
filesystem, так и будут продолжать работать с ними! Если размонтировать
tmpfs-based /tmp, "оригинальная" /tmp появится, как и прежде. Фактически,
можно монтировать любое число файловых систем на одну mountpoint, и mountpoint
будет действовать подобно стеку.
Используя bind mount, мы можем монтировать всю или только часть уже
смонтированной filesystem к другой точке и иметь filesystem, доступную
от обеих mountpoints одновременно! Например, можно использовать bind mounts
для монтирования root filesystem к /home/drobbins/nifty:
# mount --bind / /home/drobbins/nifty
Теперь, если зайти в /home/drobbins/nifty, вы увидите вашу root filesystem
(/home/drobbins/nifty/etc, /home/drobbins/nifty/opt и т.д.). Если модифицируется
файл на root filesystem, все изменения будут видны и в /home/drobbins/nifty.
Так происходит потому, что это одни и те же разделы диска, просто ядро
отображает filesystem в двух разных mountpoints. Обратите внимание, когда
происходит монтирование файловой системы к новой точке через bind-mounted,
все файловые системы, которые были примонтированы к "оригинальной", в новой
позиции отображены не будут. Другими словами, если /usr создан на отдельном
partition, после выполнения bind-mounted подкаталог /home/drobbins/nifty/usr
окажется пустым. Потребуется дополнительное bind mount, чтобы просмотреть
содержимое /usr в /home/drobbins/nifty/usr:
Bind mounting делает возможными еще более "тонкие" вещи. Например, вы
монтируете tmpfs к /dev/shm, его "традиционной" точке, но одновременно хотите
использовать tmpfs для /tmp. Вместо монтирования еще одной tmpfs к /tmp
(что возможно), вы решаете share новый /tmp с /dev/shm. Но,
bind mount /dev/shm к /tmp нужно сделать так, чтобы каталоги из /dev/shm не
были видны в /tmp. Как это сделать? Пример:
В этом примере сначала создается каталог /dev/shm/tmp и назначаются права
доступа 1777 (обычные для /tmp). Далее можно монтировать только
отдельный /dev/shm/tmp. После этого файл /tmp/foo будет дополнительно виден
как /dev/shm/tmp/foo, но файл /dev/shm/bar в каталоге /tmp отображен не будет.
Примечание переводчика. Здесь очень быстро "пролистали" тонкие вещи.
chmod 1777 /dev/shm/tmp устанавливает наследование прав в
"стиле Беркли" (единичка в аргументах). Если этого не сделать, например,
X server после перезагрузки "грохнется на старте". Второй момент - "аномальное"
наследование при монтировании. Родительский каталог (точка монтирования /tmp)
наследует свойства от дочернего каталога (/dev/shm/tmp). "Не логично",
и "по незнанию" может стать причиной проблем.
Как следует из примера, bind mounts очень сильное средство и может помочь в
проектировании файловой системы сложной архитектуры. Следующая статья будет
посвящена devfs; а пока можно посмотреть следующие ресурсы.
Linux Weekly News is a great resource
for keeping up with the latest kernel developments.
util-linux
(freshmeat link) is a collection of various important Linux utilities,
including mount and umount. You may want to upgrade to the
latest available version so that you can use the mount --bind syntax
(rather than using mount -o bind).
Since tmpfs and bind mounts are relatively new and for the most part
undocumented new kernel features, the best way to learn more about them is to
study relevant parts of the
Linux kernel sources.
You can find a very nice in-depth look at the meta-data differences
between UFS, ext2, ReiserFS, and more in Juan I. Santos Florido's Linux Gazette
Journal File Systems review.
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.
Residing in Albuquerque, New Mexico, Daniel Robbins is the President/CEO of Gentoo Technologies,
Inc., the creator of Gentoo Linux, an advanced Linux for the
PC, and the Portage system, a next-generation ports system for Linux.
He has also served as a contributing author for the Macmillan books
Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed.
Daniel has been involved with computers in some fashion since the
second grade, when he was first exposed to the Logo programming
language as well as a potentially dangerous dose of Pac Man. This
probably explains why he has since served as a Lead Graphic Artist at
SONY Electronic Publishing/Psygnosis. Daniel enjoys spending
time with his wife, Mary, and his new baby daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org.
Перевод: Владимир Холманов
Residing in Albuquerque, New Mexico, Daniel Robbins is the President/CEO of Gentoo Technologies,
Inc., the creator of Gentoo Linux, an advanced Linux for the
PC, and the Portage system, a next-generation ports system for Linux.
He has also served as a contributing author for the Macmillan books
Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed.
Daniel has been involved with computers in some fashion since the
second grade, when he was first exposed to the Logo programming
language as well as a potentially dangerous dose of Pac Man. This
probably explains why he has since served as a Lead Graphic Artist at
SONY Electronic Publishing/Psygnosis. Daniel enjoys spending
time with his wife, Mary, and his new baby daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org.