Как перенести ФС на диск бо́льшего размера?

Я так понимаю, это нужно сделать в онлайне? Или какие ограничения? Просто перенос раздела partclone-ом с последующим расширением не канает?

Можно и offline.

partclone

Почитаю.

Да как бы можно и в онлайне. btrfs replace в помощь. Будет медленнее, конечно.

У меня терабайтный винт заполнен на 95%. Много копировать. К тому же у меня ноут. Сразу два винта вставить не смогу. Придётся новый подключать по usb. Это ещё снизит скорость.

Лучше уж offline.

У ZFS это решается просто: новый диск большего объёма включается в пул как часть зеркала (сам пул зеркалится), а потом даётся команда zpool split и разделяется на два независимых пула с идентичным содержимым, но с дополнительным пространством на новом диске.

У ZFS это решается просто

А как у зфс решается с включением в ядро линукс?

Это и не нужно решать, используй FreeBSD.

А как у зфс решается с включением в ядро линукс?

А вам шашечки, или ехать?

FreeBSD

Что она может мне предложить кроме ФС, для работы которой нужно 128 ГБ ОЗУ?

На домашнем ПК: три пула ZFS (один из них RAID-Z), запущен chromium-92.0.4515.159, в котором открыто 4 вкладки (на одной вкладке проигрывается видео из Youtube), Xfce4 4.16 DE.

Системный монитор из Mate показывает: Память 1.7 ГиБ (10,5%) из 15,9 ГиБ, Подкачка 0 байт (0,0%) из 18,0 ГиБ. И где ваши «128 ГБ ОЗУ»?

Так ты фс не нагружаешь работой.

как правильно работать с zfs? (комментарий)

Rust 1.55.0 (комментарий)

Успешно перенёс ФС на новый диск hdd -> ssd.

Сначала хотел в offline режиме делать с загрузкой в livecd. Но потом подумал: у меня же хипстерская ФС с шашечками, зачем мне делать как старпёры? Надо использовать фишки ФС, чтобы раскрыть потанцевал.

Напишу инструкцию по online переносу ФС, может кому пригодится.

Примонтировал корневой subvolume hdd в /mnt, а на ssd создал один раздел btrfs и примонтировал в /ssd.

# Сделал readonly снапшот subvolume, который копирую
btrfs subvolume snapshot -r /mnt/@home /mnt/@home-ro-snap

# Перенёс снапшот на новый диск
btrfs send /mnt/@home-ro-snap | btrfs receive /ssd

# Переименовал, чтобы назывался как раньше
mv /ssd/@home-ro-snap /ssd/@home

# Снял read only флаг
btrfs property set -ts /ssd/@home ro false

# Вбил в fstab новый UUID раздела и перезагрузился
...

Так как я переносил снапшот, то мог как обычно пользоваться компом (ютубчик и т.п.) и не бояться, что из-за изменений файлов будет не консистентное состояние.

btrfs сила. Эксплуатанты ext4 жалобно хлюпают носом в углу.

btrfs сила. Эксплуатанты ext4 жалобно хлюпают носом в углу.

Узок круг этих сказочников. Страшно далеки они от народа…

Давай анон по существу. Чё там на ext4, 4 часа сидёть перед чооорной консолью, чтобы перенести ФС в offline режиме?

$ pvmove /dev/sda1 /dev/sdb1

во время компиляции хромиума на переносимом же диске

LVM? Я ФС сравниваю. Ты ещё raid приплети, там тоже данные можно размножить.

И твой sdb1 может быть больше sda1? Я про этот момент отдельно говорил в шапке.

Фейковая тема.

LVM? Я ФС сравниваю. Ты ещё raid приплети, там тоже данные можно размножить.

Ты сравниваешь неюниксвейный комбайн. И да, lvm при перемещении делает как бы raid1 (mirror) - промеренные технологии

И твой sdb1 может быть больше sda1?

Да. Если очень надо и на диске несколько томов, то можно перемещать только конкретный том pvmove -n <lv-name> ...

Ты сравниваешь неюниксвейный комбайн.

А ты предложил костыль. ФС ничего не знает про LVM.

Да. Если очень надо и на диске несколько томов

Это расширит только виртуальное блочное устройство. Мне потом в врукопашку ещё и ФС расширять. Двойная работа.

А ты предложил костыль.

Как будто копирование неизменяемого снимка - это не костыль.

ФС ничего не знает про LVM.

А зачем ФС знать о LVM? ФС здесь выступает как объект, который перемещают.

Двойная работа.

Основная задача прозрачно переместить фс. А изменить состояние фс - это отдельная задача, кстати, которую тоже можно сделать не отключая фс.

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

Неужели в бтрфс нет прозрачного перемещения данных между физическими носителями? Тогда это бесполезный комбайн.

Как будто копирование неизменяемого снимка - это не костыль.

Нет. Снимок делается моментально. Не вижу ничего плохого. Утилита btrfs send требует именно ro снимка. Ну и ладно.

А зачем ФС знать о LVM?

Чтобы не нужно было потом менять размер ФС.

Который в общем-то надо синхронизировать с актуальным состоянием

Не нужно. Я переезжал раз и навсегда. В то время, когда копировалась ФС, я смотрел ютуб. Максимум, что я потерял - историю браузера за это время. Это несущественно.

и нужна перезагрузка

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

Неужели в бтрфс нет прозрачного перемещения данных между физическими носителями?

В btrfs есть raid, но я их не использую за ненадобностью на локалхосте. LVM не даёт преимуществ, но требует больше секса.

Ну и ладно.

Согласен. Самое точное эмоциональное оценочное сужение о btrfs.

Я не понимаю, что тебя смутило в требовании ro снимков? Отличие от rw только в ключе -r при создании. Флаг ro снимается так же быстро.

Даже если бы не было этого требования, то мне rw всё равно не нужен был. Я копировал /home раздел. Он и так уже подмонтирован. Зачем мне ещё и снимок монтировать и вносить туда изменения? Похоже ты просто прицепился к этой мелочи, чтобы не признавать, что твой LVM старпёрский инструмент.

• ro
• снимок
• раздел
• монтировать

Как много ненужных сущностей наплодил ради копирования раздела.

Ну и ладно.

Я копировал /home раздел.

Я конечно жутко извиняюсь… А банальный tar не спас бы отца русской демократии?

У меня диски были одновременно подключены. Зачем мне tar архив в качестве посредника. Ещё у меня были подтома, включая те, которые автоматом генерирует докер. Нужно было, чтобы всё это не сломалось.

неюниксвейный комбайн

RedHat сделала Stratis — вроде и юникс-вэй, но в то же время говно. А теперь они снова осваивают Btrfs. Эта философия никогда не была про эффективность, не надо её натягивать на всё подряд.

банальный tar

Язабан

ЗЫ вопрос хороший

LVM? Я ФС сравниваю.

Чем функционально отличается ext4+LVM vs BTRFS?

Подтома btrfs совместно используют свободное пространство раздела. В случае LVM нужно будет самим следить и вручную менять размеры.

А если нужно свободное пространство передать от одного раздела к другому на LVM? Уменьшить размер ФС, уменьшить размер раздела, увеличить размер другого раздела, увеличить размер ФС на новом разделе. Это дрочево. Зачем вы мне приносите эту LVM? Унесите.

т.е. функционально меньшее количество ручных операций?

Для совместного использования есть «thin provisioning».

RH хотят сделать «промышленное хранилище», чтобы продавать как услугу. Но btrfs не про это, и вообще без философии. Скорее какой-нибудь ceph выстрелит, чем btrfs, в этой области.

В данном кейсе да.

thin provisioning

Здесь всё та же проблема: ФС не знает, что под ней не нормальное блочное устройство, а клоунская LVM. Я так понимаю, что технология thin provisioning строится на вранье о реальном размере блочного устройства. И что будет когда соседняя ФС высосет всё свободное пространство? Ошибка записи на уровне блочного устройства или что? Добром это не кончится.

Что происходит с бтрфс, когда место кончается?

Ничего. Там даже 12309 нет. Бессмысленная система.

Там даже

systemd нет

а что клоунского в LVM (у неё есть вполне реальные недостатки, но вы их не озвучили)? когда ты задействуешь thin provisioning, предполагается, что ты понимаешь, что делаешь, и это не дефолтное поведение.

RH хотят сделать «промышленное хранилище», чтобы продавать как услугу.

Путаешь что-то.

Скорее какой-нибудь ceph выстрелит, чем btrfs, в этой области.

RH вроде продвигает glusterfs? Ну и ты снова путаешь, потому что Btrfs сугубо локальная.

То же дрочево, но теперь с возможностью получить сломанную ФС.

Почему не btrfs device add, затем btrfs device delete ?

Тоже об этом подумал. Получился бы аналог предложенного анонимом алгоритма с LVM.

Мы говорим про ситуацию, когда блочное устройство говорит, что место есть, а на самом деле его нет. Это может произойти при записи метаданных. Когда на btrfs кончится место, то будет штатная ошибка no space left, а фс на lvm тупо умрёт.

что ты понимаешь, что делаешь, и это не дефолтное поведение.

Зачем мне решение, при котором фс может тихо умереть? Например начинаю компилять llvm или chromium, место на диске кончается и lvm убивает мне фс. Очень крутой этот ваш lvm. Восторг.

Зеркало? Насколько резво он будет делать копию? Ну т.е. я не собираюсь использовать два диска. Я хочу дождаться завершения, выключить комп и поменять диски.

Чёт мне кажется, что копирование будет в фоновом режиме. А мне нужно максимально быстро, пусть и ценой подтормаживания системы.

Эта команда не делает зеркало. Данные остаются в single. Чтобы сделать зеркало, нужна команда balance. В данном случае не нужна. https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-device

а фс на lvm тупо умрёт

У меня выжила, и даже транзакции в базе нормально откатились, но больше тонкие тома даже близко к чему-то важному не подпускал. Да, это была моя невнимательность, но всё же неприятно. Много лет назад я сам возмущался по поводу ФС-комбайнов, но сейчас понимаю, что альтернатив нет.

когда ты задействуешь thin provisioning, предполагается, что ты понимаешь, что делаешь, и это не дефолтное поведение.

Вот не могли они сделать by design, что бы всё колом не вставало, когда место заканчивается?