Ubuntu 22.04 расширение хранилища дополнительными жесткими дисками

Описание статуса:

У меня есть рабочая станция с Ubuntu 22.04 LTS и начальным NVMe (1TB). Чтобы расширить хранилище, так как оно заполнено на 98%, я добавил три диска: еще один NVMe (1T) и два HDD (каждый по 12TB). Система обслуживает нескольких пользователей через SSH.

Описание проблемы:

Я хочу расширить хранилище для всех пользователей и программ. Моя путаница связана с процессом монтирования — как обеспечить бесшовную интеграцию нового хранилища без ручного переноса данных или дополнительной настройки. Попытки использовать LVM привели к повреждению системы, и мне пришлось переустановить ее на одном NVMe.

Что было предпринято:

Я разметил все новые диски с использованием GPT и ext4. Затем я создал группу томов (vg_combined) и логические тома (lv_home, lv_var, lv_usr, lv_data), в итоге получилось следующее:

NAME                    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                       8:0    0  10,9T  0 disk 
└─sda1                    8:1    0  10,9T  0 part 
  ├─vg_combined-lv_data 252:0    0     5T  0 lvm  
  └─vg_combined-lv_home 252:1    0     5T  0 lvm  
sdb                       8:16   0  10,9T  0 disk 
└─sdb1                    8:17   0  10,9T  0 part 
  ├─vg_combined-lv_var  252:2    0     5T  0 lvm  
  └─vg_combined-lv_usr  252:3    0     5T  0 lvm  
nvme0n1                 259:0    0 931,5G  0 disk 
└─nvme0n1p1             259:2    0 931,5G  0 part 
nvme1n1                 259:1    0 931,5G  0 disk 
├─nvme1n1p1             259:3    0   512M  0 part /boot/efi
└─nvme1n1p2             259:4    0   931G  0 part /var/snap/firefox/common/host-hunspell
                                                  /

Примечание: Мое начальное хранилище было nvme1n1.

Затем у меня появилась “отличная” идея скопировать каталоги /home, /var и /usr на соответствующие логические тома, а затем монтировать их с логических томов. Это привело к повреждению всей системы, что было невозможно восстановить. После этого мне пришлось отформатировать один из nvme и переустановить Ubuntu. Я не вносил никаких изменений в остальную часть хранилища.

Вопросы:

1. Какой рекомендованный метод расширения хранилища для всех пользователей с минимальной настройкой?
2. Поможет ли создание одного логического тома, смонтированного в /data, в решении моих задач?

Извините за наивные вопросы и спасибо за внимание. Любая помощь и советы будут очень полезны.

Не существует “единственно правильного способа” сделать это, поэтому вот мои две копейки на эту тему. Ваш выбор файловой системы предполагает, что вы не знаете о btrfs. Существует также путь обновления с ext4 на btrfs, так как он считается “будущим файловых систем на Linux” ™.

Этот тип файловой системы поддерживает пулы хранилища, охватывающие несколько устройств. И самое важное изменение: она избавляется от понятия разделов, так что любой подтом может занимать все необходимое ему пространство и расти, пока пул не заполнится полностью. Вам не нужно пытаться предсказать будущее, пусть время покажет, кто и что требует. Существуют и другие полезные вещи, такие как отличное онлайн-сжатие; конечно, технология Copy-on-Write, которая позволяет делать снимки системы практически без затрат и очень дешевые “дифференциальные резервные копии” (btrfs send, см. также btrbk)

ОСТОРОЖНО: Никогда не следует “распределять” данные по разным устройствам без избыточности (так называемого RAID0) или, по крайней мере, без хорошей стратегии резервного копирования, так как отказ одного устройства приведет к повреждению всего пула, и это произойдет в очень плохой форме. Так что бесплатных обедов не бывает. И другие уровни RAID довольно противоречивы с btrfs; RAID1 довольно надежен, но очевидно требует не менее половины вашего пространства, а RAID5/6 все еще экспериментален; даже не думайте об этом.

Но, возможно, вы захотите попробовать другой подход для максимизации пространства хранилища, не живя на острие лезвия, который я применил на своем ноутбуке, который начинался с SSD на 500GB и позже получил дополнительный SSD на 1TB. Ознакомьтесь с mergerfs. Это файловая система типа union/overlay, которая позволяет прозрачно монтировать два или более разделов/подтомов (ветвей) в одну и ту же точку монтирования, запись в /etc/fstab выглядит, например, так:

# это старый VG уже в формате btrfs
# монтируем "корневой" том
/dev/mapper/vg_root  /  btrfs  subvol=/@
# home — просто подтом
/dev/mapper/vg_root  /mnt/old_home  btrfs  subvol=@home
# и новое дополнительное пространство на другом физическом носителе
/dev/mapper/vg_data  /mnt/new_home  btrfs  subvol=@home
# И вот где происходит магия
combined_home  /home  fuse.mergerfs  branches=/mnt/new_home:/mnt/old_home,x-systemd-requires-mounts-for=/mnt/new_home,x-systemd-requires-mounts-for=/mnt/old_home

Надеюсь, картина ясна. Фактически я переместил @home в отдельный подтом рядом – не ниже – @(то есть /). Таким образом, он может быть отдельно смонтирован в промежуточную точку монтирования (см. выше), как и новый @home на новом vg_data (это также влияет на снимки системы, что требует некоторого размышления перед совершением действий). И mergerfs накладывает содержимое нового /mnt/new_home поверх /mnt/old_home. Порядок ветвей важен, так как новые файлы будут (пытаться) записываться в самое верхнее устройство в первую очередь, то есть в данном случае в new_home. Можно также монтировать “старый дом” только для чтения самостоятельно, или добавлять =RO к пути ветви в строке mergerfs, т.е. branches=/mnt/new_home=RW:/mnt/old_home=RO. Таким образом, все новые данные должны быть записаны в new_home.
С учетом снимков системы (btrfs, см. btrbk, например) можно также использовать шаблоны с подстановочными знаками для ветвей и иметь что-то вроде этого:

... branches=/mnt/new_home:/mnt/old_home:/mnt/snapshots/new_home/\*,/mnt/snapshots/old_home\*,...

Таким образом, вы получите единое представление всех данных, которые еще на диске. И чтобы положить вишенку на торт, также можно добавлять ветви, когда подключен внешний резервный носитель, чтобы все файлы отображались в этом обобщенном представлении. Скажем, у вас 2TB в old_home, 4TB в new_home, 4TB снимков на диске, и 16GB на внешнем резервном носителе. Их можно объединить в один огромный “пул” из суммы их частей. Нужно быть осторожным с удалением ветвей или просто выдергиванием внешнего диска, но так как это должны быть данные только для чтения, потенциал для повреждения довольно ограничен; можно, возможно, услышать жалобу от mergerfs. Теперь я не призываю к этому в любой форме, я просто хочу показать, что это довольно надежное решение, если вы знаете об ограничениях, которые не слишком страшны.

Но я не хочу перегружать вас деталями и теряться в них. Я просто представляю один подход, который я еще нигде не видел предложенным. С ним вы можете в основном продолжать думать о своих дисках как о отдельных сущностях, если один из них выходит из строя, вы, конечно, потеряете то, что на нем, но другой все еще будет иметь все свои данные и не будет знать, что что-то не так. Также нет необходимости использовать магию btrfs для получения одного большого “пула” хранилища. Таким образом, вы можете оставить свои старые файловые системы как есть, и даже сделать новые btrfs и смешать их с “устаревшими” ext3/4. Выбирайте то, с чем вам комфортно, но потратьте время, чтобы обдумать это.

Есть небольшой подвох — это файловая система fuse, что означает, что она работает в пользовательском пространстве, то есть: узкое место в производительности, хотя по моему опыту скорость чтения/записи достаточно высокая(типа). Но если вам нужна предельная скорость, например, запись (около) без потерь UHD видео-контента в реальном времени, mergerfs не для вас.

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

Редактировать:
Всегда существует возможность непосредственного чтения или записи в подлежащие ветви. Допустим, вы хотите скопировать большой файл с максимальной пропускной способностью на внешний диск, и mergerfs для вас слишком медлителен, чисто гипотетически. И вы знаете, что файл находится в старом доме. Ничто не мешает вам `cp /mnt/old_home/path/to/file /path/to/destination’. Это дало бы вам полную производительность, какую только файловая система ядра может предоставить, полностью обходя mergerfs и его потенциальное узкое место. Большую часть времени я также делаю это при записи новых файлов, так как у меня всегда мало места и я не возражаю против дополнительных усилий; меня в основном интересует одно обобщенное представление всей совокупности при чтении и поиске файлов; и я не хочу разбивать содержимое одного каталога по нескольким ветвям на записи, что очень легко может случиться и случалось – когда mergerfs достиг ошибки “нет места”, он может переключиться на другую ветвь, если настроить на это, и попробовать снова, поэтому можно писать части каталога в одну ветвь, а другую в другую. Это особенность, а не баг. Зависит от того, хотите ли вы это использовать. Множество опций предоставляет большую гибкость.