BTRFS: сбой системного вызова mount(2): Файл существует

[Dja]

Приветы!
Накануне скопировал dd раздел в файл. Всё успешно. На ночь оставлял. Теперь не могу этот файл примонтировать. А вот соседний файл монтируется.

А вот на другом ПК тот что не смог на первом смонтировался без проблем. Почему на первом не могу?

В обоих случаях BTRFS
Вот еще что увидел

[мая29 09:46] loop0: detected capacity change from 0 to 1953521664
[  +0,003300] BTRFS warning: duplicate device /dev/loop0 devid 1 generation 396 scanned by mount (6851)

[Dja]

Немного прояснилось

[slant]

НИКОГДА не пробуй монтировать BTRFS если имеется две копии одного раздела (вот как после dd). Так до потери данных можно доиграться или не грузящейся системы. Копию делать можно, но:
1. Только offline. (в отличии от всех обычных операций над btrfs которые проводятся online.)
2. Перед попыткой монтирования - убедится что доступной ядру остается только одна копия. (Вторую нужно убрать заранее. Если это полученный от dd файл - ядро его не видит без losetup и оригинал остается рабочим, но монтировать этот файл его через loop нельзя пока оригинал доступен на исходном устройстве.)

А штатный метод копирования/переноса на другой носитель - команды btrfs send / btrfs receive. Применяются к субтомам. Т.к. работают с стандартными потоками unix то через перенаправления позволяют скопировать их и в файл, как с dd. Работают с online разделом, а потому чтобы применить send нужно сначала создать RO снапшот (с соответствующим ключом) и уже этот снапшот отправлять куда-то через send. (rw субтом просто не даст отправить - ругаться будет.)
При receive создается тоже содается RO сабтом, с которого потом делается RW снапшот. После этого RO сабтом можно убить. Такие "двухступенчатые" операции гарантируют неизменность содержимого в процессе копирования и отсутствие конфликтов доступа.

Если же нужно просто заменить диск (физический) - там еще проще. btrfs dev add новый диск (расширяем FS на второй диск, если просто так и оставить -это не raid а JBOD получится, для raid еще balance нужно сделать), и потом btrfs dev remove старый. В процессе remove данные будут перенесены (лишь бы места хватало на добавленном диске). В этом случае даже не потребуется никаких конфигов обновлять (все завязано на UUID которые в этом случае правильно изменятся), разве что сам загрузчик переустановить, если он находится на удаляемом диске.

Еще - из чата:

Если снапшоты - всего лишь изменения, то где сами файлы? К примеру. Сделал снап. Создал папку. Восстановился на снап. Куда деётся папка? Ведь если после того как сделал папку сделать еще один снап, то можно прыгать с одного снапа на другой и папка то будет то нет... Куда деваются файлы?

Здесь аналогия с библиотекой - есть книга на полке (блок тела файла), и есть ее карточка в картотеке (метаданные). У одной книги может быть несколько карточек - просто в разных разделах картотеки для облегчения поиска если книга удовлетворяет разным тематическим каталогам. Это состояние на момент снятия снапшота.
Далее представим себе, что в библиотеке у нас не просто книги, а рабочие журналы (ученых) например. И вот ситуация. Пришел новый ученый, прочитал старый журнал, и нашел ошибку в одном месте. Но сам не уверен на 100%, и просто хочет записать свой вариант опыта не теряя оригинал. Он берет чистый лист, пишет свой вариант. Кладет лист рядом с журналом, а в картотеке отмечает: "Мой журнал - это журнал Х но вместо страницы Y читать с листа который лежит рядом."
Т.е. он не переписывал весь журнал, а только тот лист, где его собственные изменения. А вот в картотеке теперь две записи - о старом и новом варианте.

Как-то так это выглядит. Разумеется у btrfs еще есть механизмы которые контролируют версионность и неизменность "слепка" на котором основано очередное изменение. Но прикол в том, что это обычный механизм COW - который работает практически постоянно.
Ну, и надо помнить, что у btrfs все это привязано не к файлу а к блоку. Т.е. если 100MB файле поменялось пара байт в другом снапшоте - для сохранения этих изменений не будет создана полная копия всего файла, а только дополнительно один блок (4 или 16kb обычно).

Ну и отвечая непосредственно на на вопрос из цитаты - когда ты восстановился на snap - ты переключился в другую версию состояния каталогов - папка осталась на том снапшоте на котором ты ее создавал. Если же удалены все снапшоты/сабтома где она есть - блоки относящиеся к ней становятся свободными и доступны для повторного использования.

В общем-то это не только btrfs касается. И на других unix FS есть такая штука как hardlinks - хардлинки, альтернативные имена файла, которые могут находится в любом месте того же раздела/диска. (Тот самый пример с картотекой, только здесь тело файла всегда одно для всех его имен, без разных версий). Так вот - удаленным файлом в unix считается тот, у которого нет ни одного имени в метаданных FS.
Hardlink может быть только у файла - но не у каталога. (В отличии от softlink'a, который к тому же может и на другое устройство вести.)

[Dja]

а потому чтобы применить send нужно сначала создать RO снапшот (с соответствующим ключом) и уже этот снапшот отправлять куда-то через send

Но ведь снапшот содержит лишь изменения... Это не будет полной копией раздела
upd... а... вспомнил... карточка
Но это опять же с btrfs на btrfs. А если на приемнике ext4?

[rogoznik]

А если на приемнике ext4?

А как ты себе это представляешь? Ведь ext4 не btrfs, а значит не знает и не умеет
Максимум что могу предположить - это предварительно снашот упаковать в tar

[Dja]

rogoznik, ну или просто cp/rsync

[rogoznik]

Dja, у btrfs есть утилита send, которая позволяет переносить снапшоты на другой раздел/диск. Но вот как себя будет вести снапшот после cp/sync/tar я хз

[Dja]

rogoznik, я не про снап. а про данные снапы это хорошо и удобно, но иногда надо иметь и иметь доступ к копии файлов
Снап удобен тем, что можно пробовать что хочешь, а потом откатываться. А я про другое

[rogoznik]

Dja, в этом случае делать копию данных cp/sync/tar/Clonezilla

[slant]

С Clonezilla те же ограничения что и dd. Она тоже образ раздела снимает.
А так - да, если нужна именно копия данных - tar/rsync в зубы и вперед (cp не так эффективен на больших объемах).

Но ведь снапшот содержит лишь изменения... Это не будет полной копией раздела
upd... а... вспомнил... карточка

Тут, для именно практического использования проще запомнить по другой аналогии: концепция параллельных миров из фантастики. Был один мир до определенного момента - потом разделился на два. И стало два независимых мира - в каждом своя жизнь продолжается независимо. Хотя в момент после разделения они были похожи как две капли, через 1000 лет может быть уже ничего общего между ними.

Карточки и т.д. - это теория о подноготной процессов, чтобы было понятно как место экономится и где подводные камни (почему снап != бекап). А на практике, для пользователя - снапшот это именно полная копия на момент его создания. Пока устройство цело - все команды btrfs тоже именно так и будут себя вести.