Руководство по продвинутым файловым системам.
Презентация 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 очень сильное средство и может помочь в проектировании файловой системы сложной архитектуры.