2006 г.
Руководство по продвинутым файловым системам.
Презентация tmpfs и bind mounts
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник : http://www-106.ibm.com/developerworks/library/l-fs3.html
Сентябрь 2001
Зачем оно нужно?
В предыдущих статьях этой серии я описал преимущества журналирования вообще
и файловую систему ReiserFS в частности. Была
описана процедура ее установки. В данной статье обратим
свое внимание на
нетривиальную тему. Сначала будет рассмотрена tmpfs, еще
известная как файловая система в virtual memory (VM). Tmpfs - вероятно лучшая
RAM disk-like система, уже сейчас доступная для Linux через новые свойства
ядра 2.4. После начального вступления рассмотрим
дополнительные возможности
ядра 2.4, называемые "bind mounts", которые добавляют много гибкости в
монтировании файловых систем.
Презентация tmpfs.
Если от меня потребуют объяснить в одной фразе, что такое tmpfs, я бы сказал -
tmpfs подобие ramdisk, но с "изюминкой".
Подобно ramdisk, tmpfs использует
ОПЕРАТИВНУЮ ПАМЯТЬ, но, кроме этого, может использовать пространство для своппинга. В то
время как
традиционный ramdisk это блочное устройство и перед его
использованием необходимо отформатировать раздел командой mkfs
с опциями,
то файловая система tmpfs - устройство не блочное, готовое к использованию
сразу после монтирования.
Такие свойства tmpfs делают ее самой привлекательной
из RAM-based файловых систем, известных на сегодняшний день.
Tmpfs и VM
Давайте посмотрим на некоторые наиболее интересные свойства tmpfs. Как было
отмечено выше, tmpfs может использовать и RAM,
и swap. На первый взгляд,
это может показаться не принципиальным, но вспомните, tmpfs еще известна как файловая система в виртуальной памяти (virtual memory
filesystem). Возможно, вы знаете, что ядро Linux "понимает"
ресурс "виртуальная память" именно как единое - целое RAM и swap-пространство.
Подсистема VM ядра ассигнует эти ресурсы другим подсистемам и управляет этими
ресурсами behind-the-scenes (прозрачно
в фоне). При этом часто без ведома
"подсистемы - заказчика" перемещает страницы ОПЕРАТИВНОЙ ПАМЯТИ между собственно RAM и swap.
Файловая система tmpfs запрашивает страницы у подсистемы VM для хранения
файлов. При этом сама tmpfs не знает, находятся ли
эти страницы в swap или
в RAM; это - "проблема" VM подсистемы. Иначе говоря, tmpfs знает лишь то,
что она использует виртуальную память.
Это не блочное устройство.
Теперь о другом интересном свойстве tmpfs. В отличие от большинства
"нормальных" файловых систем (например, ext3,
ext2, XFS, JFS, ReiserFS) tmpfs
не является "надстройкой" над блочным устройством. Поскольку tmpfs напрямую
"встроена" в VM,
ее можно монтировать сразу после создания командой:
# mount tmpfs /mnt/tmpfs -t tmpfs
После выполнения команды вы получите новую файловую систему tmpfs, смонтированную
в /mnt/tmpfs и готовую к использованию.
Обратите внимание, нет потребности в
форматировании командой mkfs tmpfs; да это и невозможно, такой
команды
просто не существует. Сразу после команды mount файловая
система доступна для использования и имеет тип
tmpfs. Это в
принципе отличается от Linux ramdisks; стандартный Linux ramdisks -
block devices и требует
форматирования перед размещением на нем файлов.
Что имеем? Монтируй и используй!
Преимущества tmpfs
-
Динамически изменяемый размер файловой системы.
Вы вероятно уже задавались вопросом, а какого размера файловую систему мы
подмонтировали к /mnt/tmpfs в примере выше?
Ответ неожиданный (особенно, если
имели дело только с disk-based файловыми системами). /mnt/tmpfs первоначально
имеет очень
маленький размер, но, по мере копирования и создания файлов
драйвер tmpfs ассигнует у VM дополнительную память, динамически
увеличивая
емкость. Справедливо и обратное, при удалении файлов из /mnt/tmpfs драйвер
отдает освобождаемую память операционной
системе. Теперь ясно (память
достаточно ценный ресурс и ее "никогда не бывает много"), большой плюс tmpfs
в том, что
используется ровно столько памяти, сколько требуется.
-
Скорость.
Другое преимущество tmpfs - ее "блестящая" скорость. Поскольку файловая
система tmpfs постоянно загружена в оперативную
память, операции записи -
чтения происходят почти мгновенно. Даже если интенсивно используется swap,
скорость все равно
высокая (более того, перемещение в swap означает передачу
ресурсов процессам, наиболее нуждающимся в памяти, что способствует
повышению
общей производительности). Итог - свойство динамически изменять размер и,
при необходимости, сбрасываться в swap,
дает возможность операционной системе
более гибко распоряжаться ресурсами. Файловая система tmpfs прекрасная
альтернатива
традиционному RAM disk с позиции скорости.
-
Безинерционность.
А вот это может считаться как плюсом, так и минусом. Как можно догадаться,
данные в tmpfs после перезагрузки будут потеряны
(оперативная память
энергозависима по своей природе. Даже после "горячей перезагрузки",
сохранившись в "физической оперативной
памяти", информация станет недоступной,
так как таблицы виртуальной памяти будут инициализированы иначе). Название
"tmpfs" само
за себя говорит. Плохо ли это? С какой стороны посмотреть.
Фактически, tmpfs превосходный резервуар для хранения временных
файлов.
Традиционно для этих целей используется /tmp и некоторые части дерева /var.
Есть даже опция - очищать /tmp при
перезагрузке, на что тратится дополнительное
время. В случае с tmpfs, такая "опция" - физическое свойство.
Использование 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 широкого применения еще не получила,
но это дело времени.
Уход от low VM conditions
А чего это мы все говорим о достоинствах? Фактом является то, что 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) очень сложно.
Решение для Low VM
К счастью, tmpfs позволяет указать максимальный размер файловой системы при ее
монтировании или перемонтировании. Фактически, с
ядром 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 с лимитом на максимальный размер достаточно просто.
Например:
# mount tmpfs /dev/shm -t tmpfs -o size=32m
В этом примере монтирование новой tmpfs происходит не к точке /mnt/tmpfs,
а к специально созданному /dev/shm. Это каталог,
который является официальной точкой монтирования ("official" mountpoint) для tmpfs. Если вы используете devfs, этот каталог
будет создан автоматически.
Если требуется ограничить размер файловой системы в оперативной памяти 512 КБ или 1 GB, можно
соответственно указать size=512k или
size=1g.
В дополнение к ограничению размера можно лимитировать число inodes (filesystem
objects) через параметр
nr_inodes=x. Где x - целое число,
возможно, с суффиксом k, m или g для обозначения тысяч, миллионов или
миллиардов inodes.
Для автоматического монтирования при загрузке системы допустимо сделать
запись в файле /etc/fstab. Например:
tmpfs /dev/shm tmpfs size=32m 0 0
Монтирование поверх занятой точки монтирования
При использовании ядер 2.2 любая попытка монтирования к уже используемой
точке монтирования приводила к ошибке. После переписи кода
ядра повторное монтирование
к занятой точке перестало быть проблемой. Такой пример: при загрузке системы
монтируется "реальный"
раздел диска к точке /tmp. Принимается оперативное
решение использовать tmpfs. В старое время потребовалось бы размонтировать
/tmp
и повторно смонтировать tmpfs в /tmp:
# umount /tmp
# mount tmpfs /tmp -t tmpfs -o size=64m
Однако не всегда это возможно. Если есть процессы с открытыми в /tmp файлами
будет выдана следующая ошибка:
umount: /tmp: device is busy
На последних 2.4 ядрах можно перемонтировать /tmp filesystem без получения
ошибки "device is busy":
# mount tmpfs /tmp -t tmpfs -o size=64m
Единственной командой ваша новая файловая система tmpfs монтируется к /tmp поверх
ранее смонтированного раздела. При этом все
новые файлы будут открываться
на tmpfs, а процессы, которые имели открытые файлы на "оригинальной"
файловой системе, так и будут
продолжать работать с ними! Если размонтировать
tmpfs-based /tmp, "оригинальная" /tmp появится, как и прежде. Фактически, можно
монтировать любое число файловых систем на одну точку монтирования, и точка монтирования
будет действовать подобно стеку.
Bind mounts
Используя bind mount, мы можем монтировать всю или только часть уже
смонтированной файловой системы к другой точке и иметь
файловую систему, доступную
от обеих точек монтирования одновременно! Например, можно использовать bind mounts
для монтирования корневой файловой системы к /home/drobbins/nifty:
# mount --bind / /home/drobbins/nifty
Теперь, если зайти в /home/drobbins/nifty, вы увидите вашу корневую файловую систему
(/home/drobbins/nifty/etc,
/home/drobbins/nifty/opt и т.д.). Если модифицируется
файл на ней, все изменения будут видны и в
/home/drobbins/nifty.
Так происходит потому, что это одни и те же разделы диска, просто ядро
отображает файловую систему в двух
разных точках монтирования. Обратите внимание, когда
происходит монтирование файловой системы к новой точке через bind-mounted, все
файловые системы, которые были примонтированы к "оригинальной", в новой
позиции отображены не будут. Другими словами, если
/usr создан на отдельном
разделе, после выполнения bind-mounted подкаталог /home/drobbins/nifty/usr
окажется пустым.
Потребуется дополнительное bind mount, чтобы просмотреть
содержимое /usr в /home/drobbins/nifty/usr:
# mount --bind /usr /home/drobbins/nifty/usr
Bind mounting для части файловой системы.
Bind mounting делает возможными еще более "тонкие" вещи. Например, вы
монтируете tmpfs к /dev/shm, его "традиционной" точке,
но одновременно хотите
использовать tmpfs для /tmp. Вместо монтирования еще одной tmpfs к /tmp
(что возможно), вы решаете
share новый /tmp с /dev/shm. Но,
bind mount /dev/shm к /tmp нужно сделать так, чтобы каталоги из /dev/shm не
были видны
в /tmp. Как это сделать? Пример:
# mkdir /dev/shm/tmp
# chmod 1777 /dev/shm/tmp
# mount --bind /dev/shm/tmp /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-сервер после перезагрузки
"грохнется на старте". Второй момент - "аномальное"
наследование при монтировании. Родительский каталог (точка монтирования
/tmp)
наследует свойства от дочернего каталога (/dev/shm/tmp). "Не логично",
и "по незнанию" может стать причиной проблем.
Как следует из примера, bind mounts очень сильное средство и может помочь в
проектировании файловой системы сложной
архитектуры.