From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FUZZY_XPILL autolearn=no autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=058Q+V6ISsaw1ILCHZzrJBuiA/EJOGCTLZwPZxSide4=; b=Q2/nkOV5g7KCsR+aF2CGGKERoZlYDpgykn20wDUI+8v7Cpm/fFxPqDRORtKchnELy7 o/iOiSC3Exq4GHFQJHRQCf8sKrT/q/FRiR06rona4+WRvN+LdDJx9tyKcRm0LJRqYAaG /X4Sb48Vhu6giejlFSkVB1GlXaPfbeR6ZEUN4/AZsOQT3Q6NKQHTmMbNRwPE5OCegulC bWLSO2GG7+Nkbtu+78niJtsouoeRH7UMfATvo8hFYUObRtBPtdlMSTLGB+f81CckD4qn VFDh1vcV2dqfkdmDmvEorXQGEcUrUA6zwqMu/w9f8P3LgEQq1PCN10l8OzVvS2nVNj0j tYig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=058Q+V6ISsaw1ILCHZzrJBuiA/EJOGCTLZwPZxSide4=; b=VrEoEWkTO2belDbiXhCjCC/dx+WDlaahMnwd9/8xoJFJeOCBbnsD6ROa5cim2H01MX 5igvTeCA1I79e89GL5P7nwhRkCrtUInpIUi+wc9f8GnLwh8zVbDec/Gk5NQY0aatyDSw Z1glsrlMy4tHWPqyrkdXGVcuzDgIdeU3gTUDy4L7/VBupQlUhtncGozLy4PY6ydfjkLZ 7LqmsCqQINDBb/Fa8a3KB2izYWxlnY8aHytpssQOxU+RwNm+6XRB14g2G17zwNrpvKe8 dRLweoHox5k59jXBkXjZ1FKYpE7ls7SlHvGWkt9G77r8Ygxt4FXGULr7QbBhuNJKmbAW FIIQ== X-Gm-Message-State: APjAAAXA2azxhqVMWde4span8F8DZzbgRLmeT6t7/ryKXl607/LuolAo K1E0+KB4+o/YAVDoP1zuvOLKCBkZ X-Google-Smtp-Source: APXvYqyLG90R/ySHj1fU4KrPSkoj/3M+LmjKIyz5j+7qhtS2Xcm+S3ZXOIq202/B5gTeVEtnivkPLQ== X-Received: by 2002:aca:edd3:: with SMTP id l202mr9042322oih.83.1567139431794; Thu, 29 Aug 2019 21:30:31 -0700 (PDT) To: devel@lists.altlinux.org References: <20190828143326.5sylulzw75hxdocx@Legion-PC.fortress> <20190828150220.GA28277@altlinux.org> <20190828151145.6imbysxtvebmv4vs@Legion-PC.fortress> <20190828152342.GB28277@altlinux.org> <20190828180827.n6mnvu4hyuqw35kv@Legion-PC.fortress> <20190828181552.GA30394@altlinux.org> <20190828195018.dgzy42qxdyzoa7u5@Legion-PC.fortress> <20190828205315.GA32468@altlinux.org> <20190828214650.yw2avjxhlmem3rdx@Legion-PC.fortress> <20190830002750.GA19971@altlinux.org> From: Leonid Krivoshein Message-ID: <98bca091-4c6e-989f-1371-709a2a656be2@gmail.com> Date: Fri, 30 Aug 2019 07:30:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20190830002750.GA19971@altlinux.org> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] /dev/shm X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 04:30:35 -0000 Archived-At: List-Archive: List-Post: 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.