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

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

sda1 ext4 / 8GB
sda2 swap 8GB
sda3 extended
sda5 ext4 /usr 20GB
sda6 ext4 /var 8GB
sda7 ext4 /tmp 4GB
sda8 ext4 /home остальное

Если традиционная мать PCшной архитектуры, то там с GPT и UEFI в 2024 году, пожалуй, даже комфортнее

Чем комфортнее? Везде делаю MBR-разделы, всё работает и удобно. На дисках больше 2ТБ (куда MBR-таблица не влезает) разделы вообще не нужны, на них надо делать mkfs на весь диск.

Когда-то давно /boot было отдельным разделом не помню из-за чего.

Я, относительно недавно, чуть больше двух лет назад, столкнулся с такой ситуацией. Когда ставил Manjaro на десктоп, с удивлением обнаружил, что grub не мог загрузиться с f2fs-раздела с включенной опцией extra_attr (вроде бы и сейчас ещё не умеет), поэтому пришлось создавать отдельный /boot раздел. До совсем недавнего времени, grub не умел грузиться и с xfs-разделов, если на тех использовалась опция nrext64.

MBR

Вредный совет. Нет никаких объективных причин это использовать на современном компьютере.

/usr

Вредный совет. Почти везде уже merged /usr, включая Debian.

/var

Спорно. Если места не хватит, будет больно. Защититься от разрастания /var/log можно квотами, если уж так беспокоит.

swap

Файл имеет такую же производительность, но гораздо гибче. Ещё zram/zswap как альтернативы.

на них надо делать mkfs на весь диск

От GPT так горит, что готов давать настолько вредные рекомендации? Лучше бы промолчал.

Вредный совет. Нет никаких объективных причин это использовать на современном компьютере.

Точно так же можно сказать про GPT, если речь не идёт про UEFI-only железо.

Вредный совет. Почти везде уже merged /usr, включая Debian.

В / лежит /etc, /boot и /root - немного удобнее когда они не пересекаются с жирным содержимым /usr.

Спорно. Если места не хватит, будет больно. Защититься от разрастания /var/log можно квотами, если уж так беспокоит.

Место в /var у меня бывало заканчивалось (из-за логов и кеша apt), никаких вредных последствий я от этого не заметил. Только логи не писались в это время. А вот если от сожравшего место /var будет disk full на / и у рута будут от этого глючить утилиты, которыми он смотрит и чинит /var (например mc упадёт с ошибкой создания /root/.config/mc/ini) - уже плохо, да.

Файл имеет такую же производительность, но гораздо гибче. Ещё zram/zswap как альтернативы.

Не знаю чем он гибче, разве что тем что при добавлении памяти можно будет увеличить и свап. zram/zswap - не альтернативы а дополнения к свапу. Обычный свап нужен для hibernate.

При этом ни источников, ни примеров нет, ага.

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

Но никак не человек, который из двух работающих решений одной проблемы (более старого и более нового) выбирает более старое. Тот, кто его называет «луддитом» — просто вешает ярлыки и характеризует исключительно себя самого.

Ну если тебе одного раздела на всё хватает — тебе GPT действительно не нужен.

GPT тут ни при чём. Речь про то что на гиганстких дисках, где всё равно будет только один раздел под файлопомойку, таблица разделов не нужна, ни GPT ни MBR. Она нужна там где раздела как минимум два. Если б мне почему-то понадобилось больше одного раздела на 4ТБ диске - сделал бы GPT. А так у меня и 1ТБ диски без таблиц разделов были по указанной выше причине. Хотя сейчас уже 1ТБ может оказаться системным местами.

И чем это вредная рекомендация?

Точно так же можно сказать про GPT, если речь не идёт про UEFI-only железо.

MBR — загрузка только в режиме BIOS (или CSM). GPT — загрузка и в UEFI, и в BIOS/CSM. Плюс чёткий писаный стандарт, а не как там сложилось в MS-DOS.

Так я и говорю, если не UEFI-only железо то с MBR нормально всё загрузится. Насчёт стандартов не надо, MBR расписан максимально детально за 30+ лет.

При этом ни источников, ни примеров нет, ага.

В англоязычной Вики, есть (дохлая) ссылка на «Compact Oxford English Dictionary». Но это достаточно легко ищется вручную, и Oxford English Dictionary сообщает, что слово «luddite» используется в значении

One who opposes the introduction of new technology, esp. into a place of work.

с 1970 года.

И чем это вредная рекомендация?

Есть соглашение — всё делается поверх разделов, даже если один раздел на весь диск. Соглашения помогают избежать ошибок. Раздел сразу хорошо видно, суперблок ФС — нет.

Во-первых, когда разделов нет, легко забыть, что там что-то есть, и потереть это. Сейчас вроде уже все линуксовые утилиты должны задетектить суперблок, но это не гарантия. Во-вторых, найдётся куча ситуаций, когда это плохая идея и по другим причинам. Первый попавшийся: диски разных моделей часто имеют немного разную ёмкость — это отличная возможность получить проблемы с MD RAID.

SSD

sda2 swap
sda7 ext4 /tmp

Наверно не лучшие решения, учитывая SSD у ТС. Есть более оптимальные - zram (своп), tmpfs (tmp).
Делают /tmp и в /dev/zram1, наверно ради выигрыша места, благодаря сжатию.

Раздел сразу хорошо видно, суперблок ФС — нет.

Да и не все ОС умеют в линуксовые фс…

У тебя никогда /var не забивался логами под завязку из-за какого-нибудь бага или кривого конфига? Ну, всё ещё впереди…

Есть соглашение — всё делается поверх разделов

Может оно у кого-то и есть, но я в него не вступал. Более того, видел и других людей которые так же делают фс на весь диск если не нужны несколько разделов.

Соглашения помогают избежать ошибок. Раздел сразу хорошо видно, суперблок ФС — нет. Во-первых, когда разделов нет, легко забыть, что там что-то есть, и потереть это.

Сложно представить такие обстоятельства. Так то в линуксе можно хоть смонтированный раздел затереть обычным dd, и никакие ни суперблоки, ни метаданные активного рейда, ни таблица разделов этому не помешает. Про утилиты более высокого уровня ты сам написал, но дело даже не в них - просто сложно представить ситуацию когда этот аспект на что-то повлияет.

диски разных моделей часто имеют немного разную ёмкость — это отличная возможность получить проблемы с MD RAID

Не «отличная», а «если очень постараться». Причин множество:

1. md raid отличился на фоне альтернатив: все h/w рейды ставят в рейд диски целиком и безальтернативно, в freebsd хоть и можно разделы вроде, но принято ставить диски целиком, и только в linux почему-то сложилось что ставят в рейд отдельные разделы; очевидно, эти мифические проблемы про «а вдруг», отсутствующие у остальных, и линукс тоже в целом не затронут

2. то, что в рейд лучше ставить одинаковые диски - общеизвестный факт

3. в новый версиях mdraid метаданные в начале, так что положение последнего сектора проблем не создаст, а если ты про ситуацию «создал рейд, он работает, меняешь диск и на новый не влезает» то разделы точно так же могут не влезть если ты разметил их впритык (как все обычно делают, я не делаю - оставляю 1гб пустое

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

5. у автора кажется не рейда и не планируется

Systemd стоит? Если стоит, то тебя ждет один неприятный сюрприз...

2024 год

MBR и фиксированные разделы

Сообщество дало вам GPT c LVM — пользуйся! Нет, не хочу, хочу жрать говно.

Как там в XIX веке, без кьюгруп? Инодов всё ещё хватает?

любая разбивка лишь бы /home отдельно был

У меня тоже SSD и разбивка именно такая. zram тоже есть но как я уже писал нужду в свап разделе оно не отменяет, как минимум для hibernate.

tmpfs (tmp)

Всё наоборот, tmpfs для tmp намного полезнее для HDD чем для SSD - дело в скорости, на HDD она будет проседать при активном использовании tmp всяким мусором из-за seek, на SSD такого нет. Про ресурс SSD беспокоиться уже 10 лет как не стоит.

в новый версиях mdraid метаданные в начале

Правда что-ли? Это залёт. Ужас как неудобно. Диск из зеркала не выдернуть и без плясок с бубном вокруг loop devices - не прочитать. Мои 2 копейки. Но я никогда софтовые RAIDы и недолюбливал (чего никогда и не скрывал).

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

https://raid.wiki.kernel.org/index.php/Superblock

metadata v1.1 - было именно так, metadata v1.2 - на 4096-м секторе от начала, вроде монтировать можно без рейда (не проверял), но куда девают настоящие данные с этого сектора не знаю, в детали не вдавался

Попробуй квоты, гораздо универсальнее.

Рута квотировать будем?

Project quota, не user.

Разбить можно как твоей душе угодно, зависит от того, какие цели ты преследуешь. Отдельные разделы имеют смысл когда тебе нужно использовать, например, разные файловые системы, ну или разные политики использования и опции монтирования, либо нужно разнести данные по разным устройствам. Для SSD имеет смысл создать отдельный var/, чтобы отделить частоизменяемые данные от редкоизменяемых, а tmp/ вообще вынести на tmpfs в ОЗУ. Так же можно отделить home/ из соображений удобства резервного копирования, или из соображений безопасности - если корневая ф.с. выйдет из строя, то ф.с хомяка останется в рабочем состоянии. Ну или оставить всё это в корне если нету каких то особых требований и предпочтений.

Давно известно. /boot и эфи отдел ными разделами, остальное в lvm

/var и /boot можно спокойно оставить в root, но /home - отдельно! Однозначно! Будешь переставлять систему, спасибо скажешь.

Для SSD имеет смысл создать отдельный var/, чтобы отделить частоизменяемые данные от редкоизменяемых

В чём смысл такого разделения именно на SSD?

нет, потому что tmpfs /var/log tmpfs nodev,nosuid,size=40M 0 0

ext2

Она разве уже доросла до прода и можно переползать с ext?

из двух работающих решений одной проблемы (более старого и более нового) выбирает более старое

Это не два работающих решения. Сейчас большинство дисков идет больше 2T и МБР их просто не поддерживает. Одно решение для современного железа, а другое решение устаревшее. Мало того, что устаревшее, оно еще и костыльное. На серьезных щщах предлагать его как альтернативу в 2k24 – признак умственной отсталости уровня «ХРЮНИКОД НЕ ВСЕМ НУЖЕН».

Давно известно. /boot и эфи отдел ными разделами, остальное в lvm

По моему глубокому убеждению - lvm в домашних условиях нафиг не впился. Лишняя сущность которая только усложняет восстановление если диск посыпется. Мнения, очевидно, могут разниться.

ESP раздел, по спецификации, должен находиться на накопителе размеченном в GPT.

В винде. Матплатам пофиг gpt или mbr, линуксу - тоже.

lvm в домашних условиях нафиг не впился

Это дефолтное решение, чтобы использовать шифрование из установщика распространенных дистрибутивов.

Сейчас большинство дисков идет больше 2T

Да ну. У тебя либо какая-то странная выборка либо просто фантазии.

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

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

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

Сейчас большинство дисков идет больше 2T

Особенно на полку в магазине с ноутбуками посмотри, ага-ага. В этом сегменте до сих пор 512 гигов предлагается как «большой диск» (а стандартным размером считается 256), что меня, например, люто выбешивает. В моей 10-летней соньке, кстати, 768, но это был ещё HDD.

признак умственной отсталости

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

чтобы использовать шифрование из установщика распространенных дистрибутивов.

Я могу поинтересоваться - что Вы там шифровать собрались? Фотографии «котиков»? Я ещё с натяжкой могу понять зачем криптовать диски на ноутах (их таки можно потерять). И то только если там какая-то значимая для бизнеса (ну, или сугубо личная, не предназначенная для посторонних глаз) информация имеется. Но дома, на стационарнике? Waste of electricity, как по мне.

Чтобы SSD не сдох

Я могу поинтересоваться

Дак человек и говорит что это дефолтное решение. Чтобы отключить, надо галочку снять с дефолта, насколько я понял.

Это не отвечает на вопрос. Я знаю, что смысла нет, но интересно было бы ознакомиться с аргументами.

Но дома, на стационарнике?

На случай сдачи по гарантии.

сугубо личная, не предназначенная для посторонних глаз

информация вполне может находиться и

дома, на стационарнике

На случай сдачи по гарантии.

Странный подход. Есть масса очень надёжных способов избавиться от данных. На HDD по крайней мере. С SSD всё даже проще - там изначально HW криптованние имеется (а если невозможно SecureErase сделать - то диск настолько «мёртвенький» что ну очень много усилий нужно приложить чтобы хоть что-то с него снять).

информация вполне может находиться и

Какова вероятность что Ваш стационарник попадёт в руки условного «злоумышленника»?

Какова вероятность

Зачем гадать о вероятностях, если можно этого не делать?

Шифрование сегодня стандарт везде: Windows, macOS, iOS, Android.

Зачем гадать о вероятностях, если можно этого не делать?

Потому как это нифига не бесплатно: Вы платите скоростью, лишней нагрузкой на CPU, и электричеством (а в случае ноутов - и временем автономной работы, что немаловажно).