Re: [devel] /dev/shm

[Leonid Krivoshein <klark.devel@gmail.com>]

30.08.2019 03:27, Dmitry V. Levin пишет:
> On Fri, Aug 30, 2019 at 02:39:34AM +0300, Leonid Krivoshein wrote:
>> [...]
>> Ещё одна tmpfs...
> Ещё и с существенно отличающимися параметрами монтирования.

Если это имеет существенное значение для хэшера, тогда понятно. Но так 
ли нужные отличающиеся параметры монтирования (несколько экземпляров 
tmpfs) в обычной системе *по умолчанию*?


>> А как это всё соотносится с повсеместной тенденцией иметь всё-таки ОДНУ
>> tmpfs на каждую систему?
> Интересно, где наблюдается такая тенденция?

Похоже, насчёт повсеместности я несколько перегнул. Посмотрел скелеты 
базовых систем разных дистрибутивов, тенденция не прослеживается. Кто во 
что горазд, даже чаще встречается отказ от /bin -> /usr/bin, от /sbin -> 
/usr/sbin и от /lib64 -> /usr/lib64. В Debian на такую схему перешли в 
2013 для упрощения перехода из stage1 в stage2 (один mount --move /run 
вместо дюжины).

FHS явно описывает разное назначение для этих каталогов: /tmp может быть 
tmpfs, но может быть и частью корневой системы, /run должна быть tmpfs, 
но преемственность с /var/run подразумевает и её чистку при загрузке, 
/dev/shm вообще не затрагивается FHS, но это всегда только tmpfs и 
отказаться от неё практически невозможно. То есть, FHS здесь можно 
трактовать по-разному, в том числе, в пользу объединения.

Контроль над параметрами монтирования различных tmpfs или пересоздания 
каталогов при запуске, помимо статических записей в /etc/fstab, 
предусмотрен только для /tmp (в каких-нибудь /etc/default/tmpfs или 
/etc/tmpfiles.d/*.conf), да и логика подталкивает к тому, что /run и 
/tmp очень схожи по сути. Для многопользовательских систем systemd 
отделяет /run/user/$UID, хотя у нас есть свой /tmp/.private/$USER, но на 
общем разделе /tmp. Для типичной однопользовательской системы нет особой 
нужды иметь столько TMPDIR'ов.

Если корневая система только для чтения, вполне логично, что у нас могут 
быть проблемы и с /root/tmp, и с /etc/udev/hwdb.bin (rpm -V udev, 
по-хорошему надо тоже линковать в /run/udev, поскольку создаётся при 
каждой загрузке). По FHS опять же /root необязателен, на практике без 
него встречал только некоторые busybox-образы, а тот факт, что для рута 
могут использоваться и /root/tmp, и /tmp немного вводит в замешательство.

Короче, клоню к тому, что проще администрировать одну tmpfs.


>
>> к тому же всё делается на tmpfs хостовой системы.
> Хостовая файловая система, вообще говоря, не обязана быть tmpfs.

Да, но так ведь практика...


>> Раз пошли вслед за остальными в этом вопросе (имеются ввиду симлинки
>> /var/run -> /run и /var/lock -> /run/lock), логичнее было бы довести это
>> до ума с остальными каталогами, которые также всегда были tmpfs. Чтобы
>> на каждую систему была только одна tmpfs:
>>
>> /dev/.* -> /run/* (к примеру /dev/.udev -> /run/udev)
>> /dev/shm -> /run/shm
> Интересно, а что такое /run/shm?

Подкаталог, создаваемый при каждом запуске после монтирования tmpfs в 
/run (в Debian и основанных на нём).


>> /dev/shm/* -> /run/*
> Прямо в run?

Да. Наверное, имеются ввиду всякие X-овые в первую очередь программы, 
всякие СУБД, которые раньше использовали для тех же целей /dev/shm -- 
теперь они могут использовать непосредственно /run, та же tmpfs.


>> /tmp -> /run/tmp
> Интересно, а что такое /run/tmp?

Тоже подкаталог, как и /run/shm.
Но я проверил, это далеко не везде так.


> Раньше размер /tmp на порядки превышал размер /run;
> с тех пор что-то изменилось?

Поскольку речь идёт о делёжке RAM+SWAP, придумывать жёсткие лимиты на 
каждый случай для схожих задач незачем. Ничто не мешает закрутить гайки 
на конкретной системе, если цели оправданы. Сейчас же мне это видится 
скорее вредным, раз всё так перемешалось и программы могут использовать 
разные пути для своих задач.


> У разных tmpfs разные задачи и, как следствие, разные параметры
> монтирования.

Разные только в плане ограничения по размеру (айнодам). Так-то задача 
tmpfs иметь быстрый доступ к данным и не захламлять диск. Большая часть 
других ограничений решается дискретной моделью доступа к подкаталогам в 
/run и общим для всего tmpfs (/run) "nosuid,noexec". Тем, кто собирает 
на tmpfs хэшером или mkimage это, понятно, не подходит. Но ведь не все 
пользователи альта занимаются сборкой, скорее меньшинство, а дефолт /tmp 
сейчас для сборщиков в ущерб безопасности. Вот для них (для нас то есть) 
/tmp можно отделить причём даже не весь /tmp, а только $TMPDIR.


-- 
Best regards,
Leonid Krivoshein.