Файловая система Linux полностью на tmpfs — скорость без компромиссов
Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.
Однако до недавнего времени мне не был известен способ, как реализовать подобное для Linux. Нет, безусловно, существует огромное количество линуксовых LiveCD, загружающихся в память при помощи опций ядра toram, copy2ram и т. д., однако это не совсем то. Во-первых, это сжатые файловые системы, обычно squashfs, поэтому любое чтение с них сопровождается накладными расходами на распаковку, что вредит производительности. Во-вторых, это достаточно сложная каскадная система монтирования (так как squashfs — рид-онли система, а для функционирования ОС нужна запись), а мне хотелось по возможности простого способа, которым можно «вот так взять и превратить» любой установленный на жесткий диск Linux в загружаемый целиком в RAM.
Но поскольку установка Debian не является предметом этой статьи, подробно ее описывать не буду.
Такой выбор в общем продиктован тем, что оперативной памяти никогда не бывает много и держать в ней что-то огромное вроде KDE не предполагалось. После установки необходимых для работы программ на жестком диске оказалось занято полтора гигабайта. Установка производилась в один раздел, без раздела swap. Оперативной памяти на компьютере установлено 16 гигабайт.
Собственно, способ
1. В файле /usr/share/initramfs-tools/scripts/local закомментируем строку:
checkfs $ root
и строку:
mount $ -t $ $ $ $
и сразу после нее вставим такой текст:
mkdir /ramboottmp
mount $ -t $ $ $ /ramboottmp
mount -t tmpfs -o size=100% none $
cd $
tar -zxf /ramboottmp/ram.tar.gz
umount /ramboottmp
2. Выполним команду mkinitramfs -o /initrd-ram.img
и после того, как она отработает, вернем файл /usr/share/initramfs-tools/scripts/local в исходное состояние.
3. В файле /etc/fstab закомментируем строку, описывающую монтирование корневого раздела / и вставим такую строку:
none / tmpfs defaults 0 0
4. Загрузим какой-нибудь другой линукс с LiveCD, чтобы полностью отвязаться от испытуемой операционной системы,
и заархивируем весь раздел с ее файловой системой:
cd /mnt/first && busybox tar -czf /mnt/work/ram.tar.gz *
после окончания вернем файл /etc/fstab в исходное состояние.
5. В итоге у нас получился линукс, состоящий всего из трех файлов:
кернела, initrd-ram.img и ram.tar.gz. Местонахождение ram.tar.gz указываем в параметре root= ядра в меню загрузчика grub:
title Linux in RAM
kernel /vmlinuz root=/dev/sdb1
initrd /initrd-ram.img
Это вся инструкция. Необходимые комментарии:
— checkfs закомментируем потому, что нет такого fsck для проверки tmpfs, не написали его;
— busybox tar используем для создания архива вместо простого tar из-за того, что в initrd нет простого tar, распаковывать наш архив будет именно busybox, и существует такой баг, что не сможет распаковать;
— звездочка в командной строке не страшна, так как в корне, обычно, нет скрытых файлов и папок, а в директориях они архивируются.
— /mnt/first — это примонтированный раздел с испытуемой ОС, а /mnt/work/ — это раздел для помещения архива.
Как это работает?
Мы изготовили специальный initrd, который при загрузке создает корневую файловую систему типа tmpfs (в этом вся соль, так как располагается она в оперативной памяти), затем смотрит на указанный в опции root= раздел, берет там файл архива, имя которого захардкожено (ram.tar.gz), и распаковывает из него все дерево ФС на эту tmpfs.
Так ФС оказывается в памяти.
Причем tmpfs обладает выгодными отличиями от рамдисков (в том числе от используемого мной для Windows) — она не блочное устройство, а файловая система, она занимает места в памяти ровно столько, сколько занимают файлы, и динамически увеличиватся, если что-то устанавливать, записывать новые файлы, и уменьшается, если деинсталлировать софт, удалять файлы. Остальная память доступна для работы ОС, программ. А еще Linux понимает, что это УЖЕ память и ее не надо кэшировать. Замечательная вещь!
Преимущества
Да, конечно, кэширование в современных ОС частично решает проблему низкой производительности дисковых устройств, но все равно необходимо время для первого прочтения файла с диска, а также он может быть выгружен из кэша в любое время и тогда понадобится время для его повторного чтения. Размещение же всей ОС в памяти является бескомпромиссным решением, гарантирующим максимально возможную скорость чтения и записи ее файлов. Простейший тест с помощью dd демонстрирует 3 гигабайта в секунду на последовательное чтение и 2 гигабайта в секунду на последовательную запись:
dd if=/dev/zero of=/test bs=1M count=500
524288000 bytes (524 MB) copied, 0.268589 s, 2.0 GB/s
dd if=/test of=/dev/null bs=1M count=500
524288000 bytes (524 MB) copied, 0.167294 s, 3.1 GB/s
Это примерно в 30 раз быстрее, чем HDD, и в 8 раз быстрее, чем SSD.
Продвинутый тест с помощью fio демонстрирует iops 349059 при случайном чтении и complete latency 0.29 микросекунд (латентность на два-три (десятичных) ПОРЯДКА меньше, чем у SSD):
В работе
Вывод команды free в типовой рабочей ситуации:
total used free shared buffers cached
Mem: 16469572 3236968 13232604 2075372 65552 2687436
Сразу после загрузки используется около 2 гигабайт памяти, из которых 1.5 занимает файловая система. При наличии 16 гигабайт ОЗУ имеется большой простор для установки даже больших приложений, как LibreOffice или Blender. Размер файла ram.tar.gz примерно полгига, что позволяет хранить его, кернел и initrd на любой небольшой флешке или на CD. Жесткого диска может вообще не быть. Такая система неубиваема. Но главное — это, конечно, скорость работы.
В заключении тридцатисекундный скринкаст о фактической скорости запуска приложений в такой системе. Нет, это не открытие приложений из трея, это запуск программ с носителя, которым в данном случае является tmpfs:
Tmpfs что это
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
В предыдущих статьях этой серии я описал преимущества журналирования вообще и файловую систему 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 очень сильное средство и может помочь в проектировании файловой системы сложной архитектуры.
Файловая система в оперативной памяти — как пользоваться tmpfs
Файловая система tmpfs может найти повседневное применение в вашей деятельности, поскольку она невероятно быстрая и может помочь снизить нагрузку на ваше постоянное хранилище (особенно актуально тем, у кого Linux установлен на флешку или карту памяти).
tmpfs — это виртуальная файловая система, располагающаяся в оперативной памяти.
Средство tmpfs позволяет создавать файловые системы, содержимое которых находится в виртуальной памяти. Поскольку файлы в таких файловых системах обычно находятся в ОЗУ, доступ к файлам осуществляется очень быстро.
Файловая система создаётся автоматически при монтировании файловой системы с типом tmpfs с помощью следующей команды:
sudo mount -t tmpfs -o size=10M tmpfs /mnt/mytmpfs
Файловая система tmpfs имеет следующие свойства:
- Файловая система может использовать пространство подкачки, когда этого требует физическая нагрузка на память.
- Файловая система потребляет столько физической памяти и пространства подкачки, сколько требуется для хранения текущего содержимого файловой системы.
- Во время операции повторного монтирования (mount -o remount) размер файловой системы может быть изменён (без потери существующего содержимого файловой системы).
Если файловая система tmpfs размонтирована, её содержимое теряется (удаляется).
Вы можете скопировать в tmpfs файлы для максимально быстрого доступа. Это могут быть файлы баз данных или веб-сервера.
Ещё одна цель использования — снизить износ постоянного хранилища. Это не особенно актуально для жёсткого диска или твердотельного диска — современные модели при любом типе домашнего использования переживут нас. Но это может быть актуально, если система установлена на карту памяти. Вы можете разместить в оперативную память приложение, которое постоянно использует хранилище (часто обращается к файлам или непрерывно сохраняет файлы), тем самым ускорится работа этого приложения, а также всей системы за счёт снижения нагрузки на карту памяти.
Ещё одна возможная причина использование — незаметность, при работе в tmpfs всё будет происходить в оперативной памяти, а на постоянных хранилищах не останется никаких следов.
Рассмотрим пример копирования файлов — насколько быстрее это будет происходить в tmpfs по сравнению с дисками.
Создадим точку монтирования:
mkdir /tmp/mytmpfs
Создадим виртуальную файловую систему размером 20 Гигабайт в оперативной памяти:
sudo mount -t tmpfs -o size=20g tmpfs /tmp/mytmpfs
Скопируем туда файл размером в несколько Гигабайт:
cp /mnt/disk_d/Vuse/Space.Cop.2016.L2.BDRip.720p.mkv /tmp/mytmpfs
Проверим, сколько времени понадобится для создания копии этого файла в оперативной памяти:
time cp /tmp/mytmpfs/Space.Cop.2016.L2.BDRip.720p.mkv /tmp/mytmpfs/copy.mkv
real 0m1,403s user 0m0,020s sys 0m1,381s
Понадобилось совсем немного времени — примерно полторы секунды.
А теперь сделаем копию этого же файла на жёстком диске:
time cp /mnt/disk_d/Vuse/Space.Cop.2016.L2.BDRip.720p.mkv /mnt/disk_d/Vuse/copy.mkv
real 0m14,463s user 0m0,065s sys 0m4,041s
Понадобилось 14 секунд — в 10 раз больше времени.
Итак, используя tmpfs можно добиться максимальной скорости доступа к файлам.
Смотрите также
- Всё о монтировании: от системного администрирования до IT криминалистики
- Опции монтирования для tmpfs
Связанные статьи:
- Как в Linux подключить новый диск, разметить и отформатировать разделы (72.2%)
- Диск Windows монтируется только для чтения (РЕШЕНО) (72.2%)
- 8 способов определить тип файловой системы в Linux (Ext2, Ext3 или Ext4, FAT32, NTFS) (72.2%)
- Почему в Linux не открывается exFAT (РЕШЕНО) (72.2%)
- Как добавлять записи в /etc/fstab. Как использовать /etc/fstab для хранения опций монтирования (72.2%)
- Что такое LVM и для чего он используется? (RANDOM — 57.2%)
tmpfs (Русский)
Состояние перевода: На этой странице представлен перевод статьи tmpfs. Дата последней синхронизации: 6 мая 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.
tmpfs — это временная файловая система, которая находится в памяти и/или вашем разделе(ах) подкачки, в зависимости от того, насколько вы её заполнили. Монтирование каталогов как TMPFS — это эффективный способ ускорения доступа к своим файлам. Также это полезно, если вам нужно, чтобы содержимое каталогов автоматически удалялось при перезагрузке.
Совет: Можно создавать временные файлы в каталогах tmpfs при загрузке системы с помощью systemd-tmpfiles.
Использование
Некоторые каталоги, где обычно используется tmpfs(5) : /tmp, /var/lock и /var/run. Не используйте его на /var/tmp, так как этот каталог предназначен для временных файлов, которые сохраняются после перезагрузки.
Arch использует tmpfs в каталоге /run , с симлинками для совместимости /var/run и /var/lock . Он также используется для /tmp в настройках по умолчанию systemd и не требует записи в fstab, если не требуется конкрентная настройка.
glibc 2.2 и выше ожидает что /dev/shm будет смонтирован tmpfs для POSIX разделяемой памяти. Монтирование /dev/shm в tmpfs выполняется автоматически systemd, поэтому ручная настройка в fstab больше не требуется.
Как правило, задачи и программы, которые выполняют частые операции чтения/записи, могут выиграть от использования каталога tmpfs. Некоторые приложения могут даже получить существенную выгоду при переносе некоторых (или всех) их данных на общую память. Например, перемещение профиля Firefox в оперативную память показывает значительное улучшение производительности.
Примеры
Примечание: Фактическое потребление памяти/подкачки зависит от того, насколько вы заполните разделы tmpfs, поскольку они не потребляют память до тех пор, пока она действительно не понадобится.
По умолчанию раздел tmpfs имеет максимальный размер в половину от всей оперативной памяти, но это можно настроить. Чтобы точно установить максимальный размер, в данном примере, чтобы переопределить значение по умолчанию для монтирования /tmp , используем опцию монтирования size :
/etc/fstab
tmpfs /tmp tmpfs rw,nodev,nosuid,size=2G 0 0
Пример с опциями монтирования для большей безопасности:
/etc/fstab
tmpfs /www/cache tmpfs rw,size=1G,nr_inodes=5k,noexec,nodev,nosuid,uid=пользователь,gid=группа,mode=1700 0 0
Смотрите tmpfs(5) и Безопасность#Файловые системы для более подробной информации.
Перезагрузитесь, для того чтобы изменения вступили в силу. Обратите внимание, что может быть заманчивым, выполнить mount -a , чтобы сделанные изменения вступили в силу немедленно, это сделает недоступными какие-либо файлы, которые в настоящее время находятся в этих каталогах (например, особенно проблематично для запуска программ с файлами блокировки). Тем не менее, если все они пусты, она должна быть безопасной для запуска mount -a , вместо перезагрузки (или смонтируйте их в индивидуальном порядке).
После применения изменений, вы можете убедиться в том, что они вступили в силу, посмотрев в /proc/mounts и используя findmnt :
$ findmnt /tmp
TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs rw,nosuid,nodev,relatime
TMPFS также может быть временно изменен, без необходимости в перезагрузке, например, когда в ближайшее время необходимо выполнить большую работу компиляции. В этом случае вы можете запустить:
# mount -o remount,size=4G /tmp
Отключить автоматическое монтирование
systemd автоматически монтирует /tmp как tmpfs, даже если нет записи в /etc/fstab . Для отключения автоматического монтирования замаскируйте юнит tmp.mount .
После этого файлы в /tmp станут храниться не в памяти, а на блочном устройстве. Содержимое /tmp теперь будет сохраняться между перезагрузками, что может быть нежелательно. Чтобы вернуть прежнее поведение и очищать каталог /tmp автоматически при перезагрузке, можно использовать tmpfiles.d(5) :
/etc/tmpfiles.d/tmp.conf
# смотрите tmpfiles.d(5) # очистка каталога /tmp всегда включена D! /tmp 1777 root root 0 # удалить файлы в каталоге /var/tmp старше 10 дней D /var/tmp 1777 root root 10d # namespace mountpoints (PrivateTmp=yes) are excluded from removal x /tmp/systemd-private-* x /var/tmp/systemd-private-* X /tmp/systemd-private-*/tmp X /var/tmp/systemd-private-*/tmp
Решение проблем
Не получается открытие символьных ссылок в tmpfs от root
Предполагая, что /tmp использует tmpfs, измените текущий каталог на /tmp , а затем создайте файл и создайте символическую ссылку на этот файл в том же каталоге /tmp . При попытке прочитать файл по символической ссылке иногда может возникать ошибка «Отказано в доступе». Это ожидаемое поведение, так как /tmp имеет установленный sticky bit.
Поведение можно настроить через /proc/sys/fs/protected_symlinks или просто с помощью sysctl: sysctl -w fs.protected_symlinks=0 . Чтобы сделать изменение постоянным, смотрите sysctl (Русский)#Настройка.
Важно: Изменение этого поведения может привести к проблемам безопасности! Отключите это, только если вы знаете что делаете.
Смотрите также
Retrieved from «https://wiki.archlinux.org/index.php?title=Tmpfs_(Русский)&oldid=773008»