(прошу перевесить куда следует) В документации пишут: > Подтома (подразделы, subvolumes) создаются ниже вершины дерева BtrFS по мере необходимости, например, для / и /home создаются подтома с именами @ и @home. Это означает, что для монтирования подтомов необходимы определенные параметры вместо корня системы BtrFS по умолчанию: > > подтом @ монтируется в / с помощью опции subvol=@; > подтом @home (если он используется) монтируется с помощью параметра монтирования subvol=@home. Здесь не написано, но @ и @home не вложены друг в друга — и это удобно, их можно независимо снепшотить, btrfs send/receive, ... Предлагаю создавать ещё и @var-cache, @var-tmp. # mount VOLUME -o subvol=@var-cache /var/cache # mount VOLUME -o subvol=@var-tmp /var/tmp Тогда эти два каталога, например, не будут попадать в снепшоты @.
(In reply to Arseny Maslennikov from comment #0) > Тогда эти два каталога, например, не будут попадать в снепшоты @. Нет смысла отделять их от системы, да и весят они копейки.
(In reply to Arseny Maslennikov from comment #0) > Предлагаю создавать ещё и @var-cache, @var-tmp. > # mount VOLUME -o subvol=@var-cache /var/cache > # mount VOLUME -o subvol=@var-tmp /var/tmp > > Тогда эти два каталога, например, не будут попадать в снепшоты @. Ещё можно рассмотреть точно так же поступать с /var/log; там свои аргументы за и против. Самый яркий аргумент "за" — прям не хочется, чтобы после восстановления @ из снимка логи отбрасывались до момента фиксации @ в прошлом.
(In reply to Leonid Krivoshein from comment #1) > (In reply to Arseny Maslennikov from comment #0) > > Тогда эти два каталога, например, не будут попадать в снепшоты @. > Нет смысла отделять их от системы, да и весят они копейки. Не могу здесь согласиться. Понятное дело, отделять можно по владению/принадлежности (могут ли две установки ОС соиспользовать раздел?), а можно по дисциплине хранения (часть установки ОС, но на другом разделе с другой ФС или даже такой же) Отделять целый /var по принадлежности не рекомендуется, а по хранению смысла нет; про этот путь я бы размышлял так же. Отделять /var/cache, /var/tmp от системы с т. з. принадлежности смысла скорее нет (т. е. если на btrfs-устройство поставить два гнулинукса dual-boot, то им нужны независимые /var/cache и /var/log и, ябсказал, даже /var/tmp). А вот по дисциплине хранения очень даже есть. У меня даже не умозрительный, а популярный пример есть. Проводим мы апгрейд, качаем пакеты, перед установкой делаем ro-снимок, ставим пакеты. откатываемся и получаем все эти гигабайты *.rpm в /var/cache/apt/archives. Отдельные subvolumes администратор потом сможет и в qgroup добавить.
> (In reply to Arseny Maslennikov from comment #0) > > Тогда эти два каталога, например, не будут попадать в снепшоты @. На это можно взглянуть и с другой стороны: должно ли их содержимое перезаписываться при восстановлении снимков других мест? Если нет, то можно вынести.
Это нужно сделать в пакетах: volumes-profile-alt-workstation volumes-profile-kdesktop volumes-profile-regular
В OpenSUSE @ @/var @/usr/local @/srv @/root @/opt @/home
(In reply to Sergey V Turchin from comment #6) > В OpenSUSE > @ > @/var > @/usr/local > @/srv > @/root > @/opt > @/home Пожалуй, можно /srv и /usr/local тоже отцепить в @srv и @usr-local. /srv — точно идея хорошая по той же причине, по которой /home. Поддерживаю полностью. /usr/local — параллельный отдельно управляемый* /usr. Отдельное им управление требует мозгов, но и применение /usr/local как таковое тоже требует мозгов. Пусть багу создаст кто-нибудь ещё, кто согласен. Зачем отселять /root и /opt, я затрудняюсь обосновать. Видимо, о вкусах и вайбах не спорят. Есть мнение (исповедуемое авторами пакета rootfiles), что /root — это не просто хомяк рута, а системный каталог. ____ * не пакетным менеджером, а иными средствами или пальцами. Надо бы завести багу на среднесрочное будущее, чтобы вся болванка /usr/local/* создавалась динамически через tmpfiles.d(5) и отсутствовала в filesystem, будучи %ghost.
(In reply to Sergey V Turchin from comment #6) > В OpenSUSE > @ > @/var > <...> А вот /var целиком вынести — это лишнее. Чтобы так делать, нужно, чтобы /var согласно политике дистрибутива был готов к тому, что он не часть базовой системы, и его можно сделать, например, пустым, не приведя софт в неконсистентное или неожиданное состояние. Гарантировать это для _всех_ пакетов в репозитории, а лучше и вообще всего совместимого ПО. Не знаю, как SuSE, а мы вряд ли потянем. Внутренности /var/cache и /var/tmp подходят, а всего каталога /var — вообще говоря, нет.
(Ответ для Arseny Maslennikov на комментарий #8) > А вот /var целиком вынести — это лишнее. Да. /var/lib/rpm/ может разъехаться с системой.
