Смешанная установка SSD+HDD с зашифрованным LVM
Не используя правые инструменты , см. , но хотя бы как альтернативу:
while read i; do
foo=$(echo -n $i | sed 's/[a-z]//g' | wc -c) && bar=$(echo -n $i | sed 's/[0-9]//g' | wc -c)
[[ $foo -eq 5 && $bar -eq 5 ]] && echo "$i has five digits and five alphas"
done < file
Удалите буквы, оставшиеся цифры и сосчитайте их. Чтобы быть тщательным, удалите цифры, оставшиеся - альфа, посчитайте их. Сохраните каждый результат в переменной:
foo=$(echo -n $i | sed 's/[a-z]//g' | wc -c) && bar=$(echo -n $i | sed 's/[0-9]//g' | wc -c)
Если переменные имеют длину 5 символов, то строка состоит из пяти цифр и пяти букв:
[[ $foo -eq 5 && $bar -eq 5 ]] && echo "$i has five digits and five alphas"
Выход:
azert12345 has five digits and five alphas
a1z2e3r4t5 has five digits and five alphas
Эта логика ошибочна?
Здесь я могу поделиться своим опытом.
На моем HP ProBook установлена Gentoo с очень индивидуальной настройкой файловой системы на SSD+HDD. Это система, в которой я сижу и пишу это прямо сейчас.
SSD (sda )имеет три раздела GPT, жесткий диск (sdb )— два.
Первый раздел на SSD (sda1 ), 127M — это ESP , это также загрузочный раздел, на котором размещена конфигурация grub, ядро и initramfs. У меня нет /boot/efi для монтирования ESP, мой /boot уже является ESP и содержит, например. /boot/EFI вместе с /boot/grub. Никаких проблем с этим.
Первый раздел на жестком диске (sdb1 ), 127M не используется. Он был задуман как «резервное пространство для размещения ESP».
Второй раздел на SSD (sda2 ), 20G, является устройством кэширования, а второй раздел на HDD (sdb2 )заполняет весь диск (500G )и является внутренним устройством. Эти два составляют для кэшированного жесткого диска — bcache0.
Этот bcache0 представляет собой зашифрованный том , внутри которого находится LVM PV, называемый pv1
Третий раздел на SSD (sda3 ), оставшееся пространство, также является зашифрованным томом, внутри которого находится LVM PV, называемый pv0.
Эти pv0 и pv1 составляют LVM VG . Поскольку все тома зашифрованы, я чувствую, что это безопасное место. В VG есть подкачка , которая размещена на pv0 и предназначена для гибернации (размер примерно равен размеру ОЗУ ), корневая файловая система только для чтения снова на pv0, который является squashfs (около 7G в настоящее время ), и r/w наложение корня ext4 также на pv0, и места не осталось. /home находится на pv1, но занимает около 300G, так что место еще осталось.
Пользовательский скрипт initramfs собирает кеш, разблокирует шифрование, собирает виртуальную группу. Он монтирует оверлей, монтирует squashfs, а затем монтирует файловую систему оверлея, где нижний уровень — это squashfs, а верхний уровень — это каталог в оверлее. Затем он переставляет монтирования, чтобы все выглядело красиво после переключателя _root, а затем переключает root.
Я успешно использую эту установку в течение полутора лет . Апгрейд очень удобный, обновляю систему как обычно (emerge -av... @world), все ставится в оверлей, потом из обновленного рута создаю новые squashfs, потом pvmove старые squashfs и оверлей на жесткий диск (pv1 )и создайте для них новые тома на SSD (pv0 ). Сценарий инициализации распознает обновленные тома и переименовывает все непосредственно перед сборкой рута, поэтому после перезагрузки новый набор томов берет на себя рут. Но старые все еще там; чтобы отменить обновление, я могу просто очистить оверлей и перезагрузиться. У меня также есть след старых squashfs (и заархивированных /boot )на внешнем жестком диске, поэтому я могу вернуться к любой точке обновления, которая у меня была ранее.
Установка выглядит довольно сложной, поэтому у меня также есть сценарии для сборки в среде live CD на случай, если мне понадобится что-то исправить.
О вашем плане.
Было бы слишком жадно тратить 1G + 650M на ESP+/boot. Я выделил на это всего 127M, в 10 раз меньше, чем вы планируете. И это все еще wa -a -ay слишком много, потому что в нем используется только 23M!
Моя корневая FS имеет около 20 ГБ необработанных данных, включая некоторые игры, STM32CubeIDE и его загрузки (около 3 -4G ), базу данных менеджера пакетов (portage )и некоторые другие огромные блобы. Это сжимается примерно до 7G. Доступ быстрый, и любому злоумышленнику довольно сложно взломать его из-за squashfs.
Я не вижу смысла размещать /var, /usr/localили /optв отдельные разделы. За свой более чем 20-летний опыт работы с Linux я никогда не сталкивался с ситуацией, когда это могло бы помочь. Верно как раз обратное :Я, конечно же, хочу, чтобы все они были согласованы и относились друг к другу, поэтому я считаю, что проще иметь их в одной файловой системе. Я называю его «системой» или «корнем», и я управляю его (резервным копированием, ротацией обновлений )в целом. Вот почему у меня никогда не было проблем с этим «отдельным /usr» и тому подобным, и я смеялся над теми, кто это делал.
Наличие /homeна отдельном разделе того стоит; стратегия резервного копирования сильно отличается, и файловая система используется совершенно по-другому. Но, помните, это /home, где у вас есть много мелких файлов для чтения и записи, особенно когда вы входите в систему или запускаете приложения — ваш профиль и конфиги. Наличие /homeна SSD гораздо важнее для воспринимаемой чувствительности машины, чем установка системы на SSD! Вот почему я использовал кэширование, чтобы улучшить работу с /home.