![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Будни локалхоста
Как-то за грандиозными облаками и AI'ками забылась простая история с администрированием локалхоста (своей собственной машины). Кажется мелочь, ерунда, но иногда оно пушает в область high-end administration.
Давным-давно, в другой стране, в другом политическом режиме, на ядре 2.6.18 на дистрибутиве Debian Etch я сделал файловую систему для ценных данных. Я выбрал в качестве файловой системы xfs, потому что на тот момент был вайб, что xfs хорошо подходит для больших объёмов с крупными файлами. Эта файловая система жила на raid1 поверх LVM, пережила несколько увлекательных приключений (включая исчезновение одной из PV в середине копирования), сменила несколько мажорных версий ядра, почти с десяток дистрибутивов (Debian etch -> Sid/Forky), неизвестное количество поколений процессоров, дисков и т.д.
И вот, случилось. 6.18 (иронично, 2.6.18 -> 6.18) отказывается монтировать эту файловую систему, ибо v4, а надо v5. Migration path нет. Шринка xfs не поддерживает. И это самая большая файловая система на моей машине.
Вообще, в моей машине осталось всего 4 блочных устройства: nvme, ssd и парочка жёстких дисков в raid1, и вот эта файловая система живёт на vg из двух жёстких дисков, размером 2ТБ (HDD 2x4TB). 2ТБ больше, чем любая другая VG на моей машине.
Пока что я откатился на 6.17 и имею доступ к файловой системе, но пришло время миграции. После долгих раздумий я решил отказаться от linux-raid и перейти на btrfs-raid, потому что btrfs способна выбрать правильную копию когда данные с обоих дисков рейда различаются, а linux-raid нет, т.к. не имеет чексумм. В новой файловой системе я буду использовать, наверное raid1+dup для метаданных и raid1 для данных.
Всё осложняется тем, что я не могу использовать LVM для btrfs, т.к. lvm поверх raid, а я хочу raid разобрать.
Мой план:
1. Прогнать long smart selftest на обоих дисках (по-очереди)
2. Сделать checking для рейда.
3. Вывести один диск из рейда, перевести рейд в linear.
4. Выведенный диск сконвертировать в новую VG, сделать LV, сделать btrfs (dup, no raid).
5. Скопировать всю файловую систему (rsync).
6. Поменять профиль btrfs на raid1
7. Оставшийся диск во вторую VG, аналогичную LV, добавить в btrfs
8. Запустить rebalance.
(отвечая на вопросы: бэкапы частично есть, частично нет и не будет, ибо жирновато для некоторых видов данных).
Вот такие вот будни localhost'а.
Давным-давно, в другой стране, в другом политическом режиме, на ядре 2.6.18 на дистрибутиве Debian Etch я сделал файловую систему для ценных данных. Я выбрал в качестве файловой системы xfs, потому что на тот момент был вайб, что xfs хорошо подходит для больших объёмов с крупными файлами. Эта файловая система жила на raid1 поверх LVM, пережила несколько увлекательных приключений (включая исчезновение одной из PV в середине копирования), сменила несколько мажорных версий ядра, почти с десяток дистрибутивов (Debian etch -> Sid/Forky), неизвестное количество поколений процессоров, дисков и т.д.
И вот, случилось. 6.18 (иронично, 2.6.18 -> 6.18) отказывается монтировать эту файловую систему, ибо v4, а надо v5. Migration path нет. Шринка xfs не поддерживает. И это самая большая файловая система на моей машине.
Вообще, в моей машине осталось всего 4 блочных устройства: nvme, ssd и парочка жёстких дисков в raid1, и вот эта файловая система живёт на vg из двух жёстких дисков, размером 2ТБ (HDD 2x4TB). 2ТБ больше, чем любая другая VG на моей машине.
Пока что я откатился на 6.17 и имею доступ к файловой системе, но пришло время миграции. После долгих раздумий я решил отказаться от linux-raid и перейти на btrfs-raid, потому что btrfs способна выбрать правильную копию когда данные с обоих дисков рейда различаются, а linux-raid нет, т.к. не имеет чексумм. В новой файловой системе я буду использовать, наверное raid1+dup для метаданных и raid1 для данных.
Всё осложняется тем, что я не могу использовать LVM для btrfs, т.к. lvm поверх raid, а я хочу raid разобрать.
Мой план:
1. Прогнать long smart selftest на обоих дисках (по-очереди)
2. Сделать checking для рейда.
3. Вывести один диск из рейда, перевести рейд в linear.
4. Выведенный диск сконвертировать в новую VG, сделать LV, сделать btrfs (dup, no raid).
5. Скопировать всю файловую систему (rsync).
6. Поменять профиль btrfs на raid1
7. Оставшийся диск во вторую VG, аналогичную LV, добавить в btrfs
8. Запустить rebalance.
(отвечая на вопросы: бэкапы частично есть, частично нет и не будет, ибо жирновато для некоторых видов данных).
Вот такие вот будни localhost'а.
no subject
no subject
no subject
P.S. А зачем под btrfs подкладывать VG?
no subject