BTRFS. Готова ли к использованию в 16.04?

[EvangelionDeath]

Sly_tom_cat, Pilot6, а не проще модифицировать сам скрипт os-prober для обработки дополнительных подтомов?

И еще вот над чем думал, может grub-efi вообще не ищет особо другие linux системы, а только в самой efi смотрит? Запись то при этом одна "Ubuntu" для разных версий Ubuntu

[Pilot6]

EvangelionDeath,

а не проще модифицировать сам скрипт os-prober для обработки дополнительных подтомов?

Проще-то оно проще, но любая модификация стандартного софта потребует поддержки постоянной.

может grub-efi вообще не ищет особо другие linux системы

Ищет через тот же os-prober. А записей с одинковым названием может быть сколько угодно. Их обычно и так две.

[EvangelionDeath]

Pilot6, требует, но все же это лучше, чем постоянное перейменовывать подтома и куда удобнее. Потом предложить тому-же каноникалу добавить это уже в пакет (после работы напильником).


Ищет и выпиливает дубли. Может в этом еще причина?

[thunderamur]

Думаю send | receive может быть быстрее чем cp. Там по сути метаданные переносятся, а не создаются на томе приемнике.

не пойму в чем выигрыш, я ведь хочу полностью перетащить, после чего исходный раздел потереть...
Пользователь добавил сообщение 01 Июля 2016, 05:26:34:

Неоднократно встречал(в этой теме тоже было) информацию, про установку нескольких систем на один раздел btrfs в разные подтома... Как это можно сделать? В гугле, ничего вразумительного найти не смог.

Сейчас стоит Xubuntu 16.04 на btrfs и /boot на отдельном разделе ext4, загрузчик в mbr. В целях тестирования ставил рядом по такому-же принципу (/boot на ext4 и / на btrfs) другие системы и получал ровно то же, что и thunderamur - новая система грузится, а старую grub просто никак не видит и все.

У меня другая ситуация, я не ставлю 2-ю систему в ту же файловую систему, я ставлю 2-ю систему на другой раздел на диске, т.е. в другую файловую систему.

[Sly_tom_cat]

Думаю send | receive может быть быстрее чем cp. Там по сути метаданные переносятся, а не создаются на томе приемнике.

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

Да хотя бы в разреженных файлах. Я выше показывал какой диф получается из пустого фала. Но когда не диф, а полный - там тоже пустоты в файлах не передаются.
Кроме того btrfs очень хорошо заточена на работу со снимками, и теми самыми дифами. Так вот всю эту мощь в полном объеме используют send и receive, тогда как cp будет тупо перетаскивать бинарные файлы..... а если оба тома (источник и приемник) использут сжатие то сначала файл разожмется, а потом сожмется. send и receive перенесут файл упакованым (насколько я понимаю).

Но это в большой степени мои предположения, что send/receive отработают быстрее cp. Вам же ни кто не мешает поставить экспереримент и нам тут рассказать - что вышло.
Всего то и нужно:

time btrfs send <путь к подтому, который копируется> | btrfs receive <точка монтирования приемника>
btrfs subvolume delete <точка монтирования приемника>/<имя скопированного подтома>
btrfs subvolume create <точка монтирования приемника>/<имя подтома для копирования>
time cp -a <путь к содержимому подтома источника> <точка монтирования приемника>/<имя подтома для копирования>

[AnrDaemon]

(Нажмите, чтобы показать/скрыть)

На форуме и в документации пишите команды полностью… Чай, не в чате и не в консоли.

[thunderamur]

Sly_tom_cat, понятно, но я данные копировал между разделами на ssd, вряд ли тут большой профит можно увидеть, скопировалось быстро и пожалось лучше, было 2.9 ГБ (lzo), стало 2.6 ГБ. Скорее всего, если на исходном сделать балансировку, то вышло бы примерно то же самое.
cp -a == cp -ar

[AnrDaemon]

'cp -a' == 'cp --no-dereference --recursive --preserve=all' …

[Sly_tom_cat]

AnrDaemon, я бы написал полностью команды - но я же не знаю что конкретно у него где и как называется.
А если ты имел в виду сокращения типа su cr вместо subvolume create - то это вполне допустимые сокращения команд btrfs - не вижу большого смысла писать их полностью, если по двум буквам работает. Кто не понял - лучше пусть спросят, а копипаст - не пройдет из-за того что не указаны пути.
Пользователь добавил сообщение 01 Июля 2016, 12:16:56:thunderamur, ну так я и предлагаю - не предполагать, а просто проверить.

[AnrDaemon]

Я имел в виду - не сокращать "subvolume create". А что ты имел в виду под "su re", я вообще не понял.

[Sly_tom_cat]

AnrDaemon, su re de = subvolume remove delete

Когда довольно часто пользуешся этими командами то таких вопросов не возникает.

[AnrDaemon]

Не все пользуются ими часто, кто-то вообще впервые на этот топик набрёл.
А в моих btrfs-tools нет sub remove.

[Sly_tom_cat]

remove - мой косяк - признаю - там не remove, а delete (коротко - de).

[Venom13]

... Не может именно такой командой. Можно делать с помощью файлов. Если на удаленном сервере тоже btrfs, то он скушает файл дифа, и будет то же самое. ...

Вполне можно.

Код: [Выделить]

ssh <user>@<IP> -p <port> "btrfs send /<point_in>/" | sudo btrfs receive -v /<point_out>/Но! Кто-нибудь в курсе возможно ли продолжить прерванную синхронизацию?

А то в случае ошибки (например кратковременный обрыв интернета) мы получаем не полную копию..
Повторный запуск синхронизации упадет в "такой файл уже есть на той стороне".

Ведь тогда и в скриптах автоматического резервирования имеет смысл проверять удачность копии, перед удалением базового снепшота.
Иначе можем потерять весь архив копий. (если попытаемся использовать в  качестве базового снимка - не полный снимок) 
И "на той стороне" надо как-то проверять на сколько последняя копия была удачной. Прежде чем присваивать ей номер, и отправлять в архив.
 
Вообще, достаточно много ситуация, в которых может "что-то пойти не так".. 

Файлы - выглядят, по началу, как лишний элемент. Но с ними больше идей как добиться отказоустойчивости...

[Sly_tom_cat]

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

Но нужно понимать - файл в придачу еще и проблема места - т.к. его нужно сохранить на передающей стороне пока не подтвержден прием на приемной. Ладно если это диф, а если это первоначальный, т.е. полный бекап... 

Но мне кажется за счет дифов - проблема разрыва и большого файла относится только к самой первой, полной копии. По дифам это все не так критично - они должны быть не слишком большие.... в теории....