Помогите пофиксить btrfs на lvm (luks) после ресайза

Счас комп врубаю (я не помню точно, может за другим был, но мне казалось, что в первый раз он запустился нормально и работал)

Наркотики это плохо

Feb 22 20:59:55 comp kernel: ata1.00: failed command: READ FPDMA QUEUED
Feb 22 20:59:55 comp kernel: ata1.00: cmd 60/08:a0:60:af:be/00:00:01:00:00/40 tag 20 ncq dma 4096 in
res 51/40:08:60:af:be/00:00:01:00:00/40 Emask 0x409 (media error) <F>
Feb 22 20:59:55 comp kernel: ata1.00: status: { DRDY ERR }
Feb 22 20:59:55 comp kernel: ata1.00: error: { UNC }

У тебя с новым диском проблемы.

У тебя с новым диском проблемы.

Хмм. Я взял бокс внешний, диск был отличный этот. Подключил старый диск через бокс, сделал dd if=/dev/sdb1. Потом создал контейнер LUKS на оставшееся место, оба примонтировал и сделал dd содержимого одного в другой. Потом пару дней отлично раотало всё. Потом сделал ресайз. Кстати, вспомнил ещё, ноут валялся на краю дивана, высота была небольшая (менее полуметра). Кошка бегала по квартире и прыгнула на него, он неторопясь съехал с дивана и упал, ударился совсем слегка. Обидно, если он мог сдохнуть от этого(( Попробую раскрутить комп и перевоткнуть...

Попробуй для начала посмотреть в SMART и запустить SMART long self-test.

Попробуй для начала посмотреть в SMART и запустить SMART long self-test.

Ошибки нашёл при долгом тесте. Видимо, при падении ноута что-то произошло. Кабель воткнут плотно, комп разбирал и перевтыкал.

«Read element of the test failed»? Это битые секторы. Кабель ни при чём, тестирование проводит сама прошивка диска.

Значит:

• ФС ты уже не починишь — бери старый диск (если не стёр его ещё);
• По-хорошему диск надо менять или хотя бы иметь новый наготове;
• Секторы можно заремапить принудительной записью в них (данные это не восстановит, но диск снова будет относительно пригоден к использованию).

Восстановил впринципе всё на старый диск, за исключением одного проекта, профиля фаерфокса, и хотелось с гуя полазить и посмотреть, возможно я что-то нужное ещё скачал. Поэтому хотелось бы примонтировать дамп к живой системе. Возникли проблемы с одинаковыми UUID. В случае с LVM, проблема решилась так. Примонтировал диск с загрузочной флешки и сделал для бекапа

vgchange -a n /dev/lvmvg
pvchange -u /dev/mapper/root
vgrename lvmvg lvmvgcp

tldr: It's ok, no possible data corruption.

Asked at the mailing list too, and they explained that the subvol UUID is just used a sanity check for btrfs send and btrfs receive.

... The UUIDs on subvols are only really used internally to that filesystem, so the kernel doesn't have a chance to get confused. The main thing that could be confused is send/receive, but that's a matter of possibly losing some validation (thus allowing you to do something that will fail) rather than causing active damage, as in the duplicate-FS-UUID case. ...

from http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/focus=50917

Но есть проблема. Как только я в работающей системе открываю контейнер LUKS c бекапом, он всё равно начинает пытаться работать с ФС оттуда, вместо основной. Например, пытаюсь выполнить команду $mount ..., выдаёт Input/Output error: mount, lsлс срабатывает, но показывает содержимое бекапной директории, вместо основной (с некоторыми повреждёнными файлами), ну и разные куски плазмы падают. Как понял, это баг и побороть не смогу?