LINUX.ORG.RU
ФорумAdmin

Современная разбивка диска

 


0

4

Давно прошли те времена, когда диск скрупулезно разбивали на 4 раздела -
/boot, /root, /home и даже /var.

Нынче можно не заморачиваться и запихнуть всю эту музыку в один раздел, и оно будет нормально грузится и устойчиво работать.

Сейчас хочу рационально разбить SSD диск сравнительно небольшой емкости в 256 ГБ.

Swap обязательно оставлю. мало ли что.
Root и Home помещу в один раздел.

А вот что делать с Boot - быть или не быть?

Если быть, то какую ФС лучше выбрать?
Потому что заметил, что на всяких там Raspbian и т.п. выбирают даже старинную FAT32.

С чем связан такой выбор - увеличивает скорость загрузки или что?

★★★★★

Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от anonymous

груб умеет полнодисковое шифрование, отдельный boot не нужен

Когда последний раз пробовал, что в федоре что в дебиане отдельный boot создавал инсталлятор. Если мудохаться через консоль, может и не нужен, но кому это надо.

А ещё есть клёвая фича - не знаю как это работает, но когда вводишь пароль для диска, оно и в гном может логинить с тем же паролем. Короче чтобы два раза не вводить пароль (если он одинаковый). Уверен, что grub так не делает.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
31 октября 2024 г.

Сейчас наверное отхвачу, но у меня так:

GPT
|- /efi - 2Gb - лежит ядро и live дистрибутив если надо что-то починить или арч сломали и надо откатиться
|- encrypted swap - 20Gb
|- dmcrypt остаток Gb
    |- btrfs 
        |- /root - /
        |- /root_snapshots
        |- /home - /home
        |- /home_snapshots
        |... остальные subvolume по вкусу для исключения из снапшотов

Система на данный момент пережила переезд между 3мя различными железяками (desktop на AMD Ryzen -> thinkpad T14 gen1 -> framework 13), EFI + Secure Boot + TPM. Усилия при переезде были минимальными, BIOS переводился в режим добавления сертификатов, запускалась ось, добавлялись сертификаты, после enroll в TPM и счастье. 2-3 минуты максимум.

ksim
()

Давно прошли те времена, когда диск скрупулезно разбивали на 4 раздела - /boot, /root, /home и даже /var.

Кто тебе это сказал?

На разные разделы части системы устанавливают по разным причинам. Основной причиной разбивки дисков есть безопасность обеспечиваемая опциями монтирования:

/boot nodev,noexec,nosuid,ro
/ nodev,ro
/dev noexec,nosuid,rw
/home nodev,noexec,nosuid,rw
/var nodev,noexec,nosuid,rw
/tmp nodev,noexec,nosuid,rw
...

Важно, чтобы разделы смонтированны exec были неизменяемы ro, а разделы смонтированы для записи rw не имели возможность исполнятся noexec. Также следует запрещать nodev и nosuid для разделов доступных на запись пользователям.

anonymous
()
Ответ на: комментарий от Pierre_Dolle

В некотором случае и правда не нужен, с ним куб не стартует.

Во-первых, kubernates — это не тот софт, который крутится на машине среднестатистического пользователя ПК. Во-вторых, где подробности? Почему cubernates не работает со свапом?

hateWin ★☆
()

Нужно от большего к меньшему разбивать: корень (монтируешь в него /), загрузочный раздел (/boot) 512-1024MiB. Всего два раздела нужно. Своп не нужен, так как гибернация бесполезна на SSD, так как все и без нее грузится мгновенно, а для других целей хватает ZRAM. Если нужен будет своп-раздел, откусишь от корневого… Под винду тож самое

rtxtxtrx ★★
()
Ответ на: комментарий от TPPPbIHDELj

Потому что ZRAM. Любители линупсав довольно таки консервативные персонажи + невероятно ленивые, поэтому инструкций с файлом подкачки меньше чем с разделом, а про ZRAM еще реже вспоминают, вот все про этот раздел подкачки никому давно невсравшийся вспоминают.

rtxtxtrx ★★
()
Ответ на: комментарий от rtxtxtrx

Нужно от большего к меньшему разбивать

а в чём тайный смысл? Ну ладно раньше чтоб swap был поближе к центру блина, но сейчас то зачем?

Своп не нужен, так как гибернация бесполезна на SSD

А если как своп? Чтоб из памяти редкое и ненужно вытеснялось в своп, освобождая место для системных кешей ускоряя работу с тяжёлыми проектами?

ksim
()
Последнее исправление: ksim (всего исправлений: 1)
Ответ на: комментарий от ksim

в том что если загрузочный раздел первый, то его размер не изменить без уменьшенмия и перезаписи всех данных следующего после него. это так очевидно… тем кому неочевидно… я их заранее не уважаю

rtxtxtrx ★★
()
Ответ на: комментарий от rtxtxtrx

да уж, у меня наоборот проблемы только были, когда новый SSD берёшь размером побольше и надо рут раздвинуть, и тут начинаются двиганния через другие разделы.

ksim
()
Ответ на: комментарий от rtxtxtrx

Нужно от большего к меньшему разбивать

...

в том что если загрузочный раздел первый, то его размер не изменить без уменьшенмия и перезаписи всех данных следующего после него. это так очевидно… тем кому неочевидно… я их заранее не уважаю

Вы уж определитесь с показаниями.

anc ★★★★★
()
Ответ на: комментарий от Pierre_Dolle

Лучше тогда запускать его в отдельном cgroup и отрубить для этой группы свап (задать лимит или выкрутить swappiness в ноль). Отключать свап на системе общего назначения — плохая затея

hateWin ★☆
()
Ответ на: комментарий от hateWin

кубер для серваков, а на серваке всегда своп отрубают, чтобы процесс не висел по два часа, не давая подключиться по ссх, а сразу убивался. и вообще кубер не нужен никому и никогда, а хайлоад — это миф и разводка лохов на деньги

rtxtxtrx ★★
()
Ответ на: комментарий от hateWin

Оно не оч работает, а кубадм по дефолту ругается. Ну короче, так то можно конечно, но лучше не надо.

Кстати можно его вообще по идее тупо в докере запустить, если тупо апи надо для тестов.

Pierre_Dolle
()

Нынче можно не заморачиваться и запихнуть всю эту музыку в один раздел, и оно будет нормально грузится и устойчиво работать.

я так делал в 2000. делаю и в 2024. по моим ощущениям ничего не поменялось. можно я и дальше буду так делать?

alt-tab-let ★★
()

Попробую расписать моё понимание и мой подход.

Если система грузится через UEFI, нужен системный EFI раздел. Он по правилам должен форматироваться через FAT. Там должен находиться файл /EFI/BOOT/BOOTX64.EFI.

Если используется шифрование корневого раздела, обычно используется отдельный boot раздел.

EFI раздел и boot раздел разумно совместить, если на компьютере установлена одна ОС.

На десктопе может быть смысл использовать отдельный home раздел, чтобы иметь возможность легко переустанавливать систему. Хотя я не использую отдельный home раздел.

На сервере я порой использую отдельные разделы, главная задача которых - переполняться без влияния на сервер. К примеру если на сервере установлены производственная и тестовая среды, будет неприятно, если переполнение тестовой БД приведёт к неработоспособности производственной БД. Также я сталкивался с ситуацией, когда каталог /var/log не чистился и это через некоторое время приводило к неработоспособности всего сервера. В идеале, конечно, логи должны ротироваться и всё такое, но на практике может быть смысл перестароваться и сделать для этого каталога отдельный раздел.

В принципе это всё можно реализовать без разделов, а с помощью квот на каталоги, но я так не пробовал.

Для swap пространства я тоже предпочитаю отдельный раздел.

Таким образом сейчас у меня используются три раздела на моём компьютере:

/boot, отформатированный как FAT32 и использующийся одновременно как EFI раздел.

зашифрованный /

зашифрованный swap

vbr ★★★★
()
Ответ на: комментарий от Pierre_Dolle

Эта информация давно устарела. Kubernetes с версии 1.22 поддерживает Swap.

https://kubernetes.io/blog/2024/03/12/kubernetes-1-30-upcoming-changes/#node-memory-swap-support-kep-2400-https-kep-k8s-io-2400

https://kubernetes.io/docs/concepts/architecture/nodes/#swap-memory

тут можно почитать про актуальное состояние

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от vbr
~
❯ sudo parted /dev/nvme0n1
[sudo] password for sergey:
GNU Parted 3.6
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Netac NVMe SSD 1TB (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  483GB   483GB
 2      483GB   999GB   515GB   ntfs               msftdata
 3      999GB   1000GB  1074MB  ext2               bls_boot
 4      1000GB  1000GB  537MB   fat32              boot, esp

bls_boot — это расширенный загрузочный раздел специально для монтирования /boot. ESP можно монтировать в /boot, но если не нравится, что загрузчик ругается на права можно сделать все правильно. Правда, для загрузки ядра с расширенного раздела нужно драйвера фйаловой системы кинуть в /efi/EFI/systemd/drivers:

~
❯ yay -Ql efifs | grep x64
efifs /usr/lib/efifs-x64/
efifs /usr/lib/efifs-x64/affs_x64.efi
efifs /usr/lib/efifs-x64/bfs_x64.efi
efifs /usr/lib/efifs-x64/btrfs_x64.efi
efifs /usr/lib/efifs-x64/exfat_x64.efi
efifs /usr/lib/efifs-x64/ext2_x64.efi
efifs /usr/lib/efifs-x64/f2fs_x64.efi
efifs /usr/lib/efifs-x64/hfs_x64.efi
efifs /usr/lib/efifs-x64/hfsplus_x64.efi
efifs /usr/lib/efifs-x64/iso9660_x64.efi
efifs /usr/lib/efifs-x64/jfs_x64.efi
efifs /usr/lib/efifs-x64/nilfs2_x64.efi
efifs /usr/lib/efifs-x64/ntfs_x64.efi
efifs /usr/lib/efifs-x64/reiserfs_x64.efi
efifs /usr/lib/efifs-x64/sfs_x64.efi
efifs /usr/lib/efifs-x64/udf_x64.efi
efifs /usr/lib/efifs-x64/ufs2_x64.efi
efifs /usr/lib/efifs-x64/xfs_x64.efi
efifs /usr/lib/efifs-x64/zfs_x64.efi
rtxtxtrx ★★
()

По современным, да и не очень, реалиям самым оптимальным по моему скромному мнению будет следующее: Имеем SSD и HDD, на первом всё, что не меняется часто, а именно – /dev/root, /boot/EFI, если используется оный. На HDD выносятся /var и /home, по понятным причинам, swap-раздел туда же. /tmp монтируется в память. UPD. Ах да, выкинуть уже BIOS boot на мороз, только GPT. Всё остальное – от лукавого.

yars068 ★★★★
()
Последнее исправление: yars068 (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

если не нравится, что загрузчик ругается на права можно сделать все правильно

О чём именно речь? У меня была похожая проблема - systemd-boot ругался на то, что /loader/random-seed является доступным для чтения, но я решил её кардинально: монтирую /boot с опциями fmask=177,dmask=077. Обычному юзеру там в итоге ничего не видно, но зачем ему туда смотреть. А так вроде теперь никто не ругается и всё работает.

vbr ★★★★
()
Ответ на: комментарий от krasnh

Делают /tmp и в /dev/zram1, наверно ради выигрыша места, благодаря сжатию. Делают, но только не всегда это полезно, потому что взамен оно начинает грузить проц. Кого-то это устраивает, кого-то (меня, например) – нет.

yars068 ★★★★
()
Ответ на: комментарий от yars068

На HDD выносятся /var и /home, по понятным причинам, swap-раздел туда же.

по понятным причинам

Нет, не понятным. /var ещё ладно, но уж /home точно на SSD в первую очередь стоит держать.

CrX ★★★★★
()
Ответ на: комментарий от CrX

но уж /home точно на SSD в первую очередь стоит держать.

Даже если стоимость данных гораздо выше стоимости SSD и бэкапов вместе взятых? Как ни крути, а HDD гораздо надежнее SSD. Перестраховываюсь? Возможно. Но, по мне, лишние несколько миллисекунд (или даже секунд) скорости случайного доступа не стоят потраченного времени и, вероятно, нервов, на восстановление из бэкапа, тем более, что бэкап, как ни странно, полностью от потери данных не спасает. Он поможет, но если со времени крайнего бэкапа были новые изменения – то увы, эти изменения теряются. А с HDD вероятность потери данных все-таки меньше…

yars068 ★★★★
()
Ответ на: комментарий от anonymous

Тоже никакого смысла.

Ну у меня вот /var/cache/xbps и /var/cache/pacman вынесены. Там скорость не нужна: всё скачиваемое относительно мелко, и ставится по сути из файлового кэша, и пофиг когда запишется, а если уж понадобилось даунгрейднуть какой-то пакет, то лишние несколько милисекунд погоды не сделают. Нет никакого смысла держать это на SSD — таким данным самое место на HDD, благо его навалом.

Да вообще не вижу смысла использовать HDD в ПК

Они тупо дешевле и больше по объёму. И при этом есть целая куча данных (кстати, самых крупных по объёму, как правило), которые никак не выиграют от SSD. Хоть бы даже те же видео и музыка.

CrX ★★★★★
()
Ответ на: комментарий от yars068

Даже если стоимость данных гораздо выше стоимости SSD и бэкапов вместе взятых?

Конечно. От этого будет зависеть количество бэкапов. Ну и бэкапы, естественно, на рейд из HDD. Но это же не повод тормозню в хомяке терпеть. Вообще одно к другому не относится, даже если не считать, что:

Как ни крути, а HDD гораздо надежнее SSD.

Это весьма и весьма спорное утверждение.

Но, по мне, лишние несколько миллисекунд (или даже секунд) скорости случайного доступа не стоят потраченного времени и, вероятно, нервов, на восстановление из бэкапа

Во-первых, стоят, потому что эти секунды складываются в гораздо больше времени, а главное нервов на постоянке, а не в случае ЧП. Во-вторых, HDD от восстановления из бэкапа ни разу не спасает.

из бэкапа, тем более, что бэкап, как ни странно, полностью от потери данных не спасает. Он поможет, но если со времени крайнего бэкапа были новые изменения – то увы, эти изменения теряются.

Вообще-то для этого существует RAID. Да, для ценных данных: сами данные на RAID, бэкапы — на другой RAID на другой физической машине (желательно ещё и в другом физическом помещении, но это ладно). Элементарные вещи же.

А с HDD вероятность потери данных все-таки меньше…

Опять же, очень и очень сомнительное утверждение. И даже если оно вдруг окажется правдой (для каких-то конкретных HDD и конкретных SSD — запросто может), надо ещё и учитывать насколько меньше.

А то так можно везде исключительно пешком ходить, ну хотя бы в пределах континента. Ведь на любом транспорте шанс попасть в аварию выше (причём разница гораздо существеннее и очевиднее, чем в случае с SSD/HDD).

CrX ★★★★★
()
Ответ на: комментарий от rtxtxtrx

а на серваке всегда своп отрубают

Вы здоров?

чтобы процесс не висел по два часа, не давая подключиться по ссх, а сразу убивался

Точно не здоров. Лечиться вам батенька нужно.

anc ★★★★★
()
Ответ на: комментарий от hateWin

Мне так кажется что если система пытается регулярно использовать swap то надо не раздел для него выделять,а оперативной памяти добавить. Сколько именно - зависит от потребностей и задач.

Если же сильно жрущие память задачи встречаются редко то для этого в комплекте Дебиана есть демон,который сам по потребности создает и подключает swap в виде файлов. (пакет называется swapspace).

У меня сильно прожорливых до памяти задач нет, поэтому я уже не первый десяток лет пользуюсь этой штукой,не выделяя отдельный раздел.

watchcat382
()