файловая система доступна только для чтения

Любые экземпляры этой ФС долго не живут

4.2

$ df -h .
Файловая система     Тип   Размер Использовано  Дост Использовано% Cмонтировано в
/dev/mapper/storage1 btrfs   7,3T         4,3T  1,6T           74% /mnt/data

$ sudo find . -exec stat -c '%W %n' {} \; | sort -n -k1 -r | tail -n2 | while read btime name; do echo "$(date -d "@$btime") $name"; done

Ср мая 13 14:50:48 MSK 2015 ./lost+found
Чт янв  1 03:00:00 MSK 1970 .

ибо defective by design

Анонимные архитекторы снова на ЛОР пожаловали?

монтировал так mount -o subvolid=0 /dev/sdb1 /mnt

Так пойдёт. Я бы на твоём месте забэкапил всё сразу командой вида tar -cf /path/to/backup.tar -C /mnt ., а разбирался бы уже потом. Бэкапить подтома по отдельности (как ты пишешь тут) смысла никакого.

на сколько я понимаю, его можно будет потом смонтировать и из него вытащить все необходимое

Да.

если можно объясни один момент, dd ведь сохраняет образ жд полностью с учетом структуры поломанной фс и неразмеченного пространства

Это правда.

предполагаю, что я его смонтирую, а потом с помощью rsync всё это дело раскидаю по вновь созданным разделам, интересует вероятность поймать что-то невразумительное

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

ну и еще у меня есть все в tar, какой способ корректней?

Как я уже сказал, вообще как только ты замечаешь, что у тебя побилась ФС, следует снять посекторный образ и дальше работать уже только с ним. Но если у тебя уже есть обе копии — то вообще без разницы.

Поэтому лучше делай несжатый

ок, уже выпилил еще места, щас буду несжатый делать, а монтируется он какой командой? нашел что-то типа

mount -t auto -o loop /mnt/HDD/backup.img /mnt/backup/

щас еще делаю сжатый образ жд

или так паковать диск плохая идея?

Не то чтобы «плохая», но сжатый образ ты не сможешь примонтировать. Тебе придётся сначала где-то найти место, чтобы его распаковать.

Поэтому лучше делай несжатый, а если не хватает места — делай sparse-образ: dd if=/dev/sdb bs=1M conv=sync,noerror,sparse status=progress of=/path/to/backup.img.

mount /path/to/backup.img /path/to/mountpoint -o ro,loop, всё правильно.

sparse типа игнорирует свободное место?

Если очень грубо — то да. Более точно — пропускает (резервирует место, но не копирует) нулевые блоки. Поскольку у тебя SSD и ты, надеюсь, пользовался TRIM’ом, то свободное место на исходной ФС у тебя будет по большей части состоять из нулей.

Поскольку у тебя SSD и ты, надеюсь, пользовался TRIM’ом

пользовался

то свободное место на исходной ФС у тебя будет по большей части состоять из нулей.

теперь ясно, почему в свойствах @home показывало 11 G, а архив содался на 34 G

теперь ясно, почему в свойствах @home показывало 11 G, а архив содался на 34 G

Какой архив? tar или посекторный образ?

tar

Тогда это ничего не объясняет, скорее наоборот. Возможно, у тебя на самой ФС были sparse-файлы? Или просто на повреждённой ФС после repair’а (особенно учитывая, что он упал посередине процесса) подсчёт свободного места неправильно работает?

подсчёт свободного места неправильно работает?

сейчас проверил, уже вообще говорит «некоторое содержимое нечитаемо», видать сказывается даже в режиме -ro и фс продолжает сыпаться

Тогда не удаляй свои первоначальные tar-ы и восстанавливай с них.

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

# mount /mnt/HDD/backup.img /mnt/backup/ -o ro,loop
mount: wrong fs type, bad option, bad superblock on /dev/loop4,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

чт не так?

ладно, я понял. это шляпа, буду из тара пробовать восстанавливаться...

In some cases useful info is found in syslog - try dmesg | tail or so

In some cases useful info is found in syslog - try dmesg | tail or so

[ 1856.843020] BTRFS info (device sdb1): disk space caching is enabled
[ 1856.843022] BTRFS info (device sdb1): has skinny extents
[ 1856.875699] BTRFS info (device sdb1): detected SSD devices, enabling SSD mode
[ 1887.721058] BTRFS critical (device sdb1): corrupt leaf, slot offset bad: block=56930156544, root=1, slot=77
[ 1887.721063] ------------[ cut here ]------------
[ 1887.721075] WARNING: CPU: 1 PID: 1867 at fs/btrfs/extent-tree.c:6962 __btrfs_free_extent.isra.33+0x85c/0xcd0 [btrfs]
[ 1887.721076] BTRFS: Transaction aborted (error -5)

BTRFS: error (device sdb1) in __btrfs_free_extent:6962: errno=-5 IO failure
[ 1887.721201] BTRFS info (device sdb1): forced readonly
[ 1887.721202] BTRFS: error (device sdb1) in btrfs_run_delayed_refs:2967: errno=-5 IO failure
[ 1887.729337] BTRFS error (device sdb1): pending csums is 53248
[ 1936.156688]  loop4: p1

это из того что выделено красным цветом

Вообще битые ФС (не только btrfs) нужно монтировать с -o ro,norecovery, а не просто -o ro. Но в твоём случае, возможно, уже поздно.

привет, начал распаковку командой

sudo tar --same-owner -xvpf /mnt/sda5/root.tar.lzma -C /mnt/btrfs/\@

или распаковывать как есть, а потом с помощью mv подправить?

Да. Если распаковываешь снова на btrfs — можешь заранее создать подтома на правильных местах, т. е.

btrfs sub create /mnt/btrfs/@
btrfs sub create /mnt/btrfs/@home
...
tar -xaf /mnt/sda5/root.tar.lzma -C /mnt/btrfs

в общем я примонтировал ссд в mnt/ssd/ и начал распаковывать так

sudo tar --same-owner -xvpf /mnt/sda5/root.tar.lzma -C /

так и сделал, только еще добавил @cache и @snapshots, когда переносил систему на бтрфс в первый раз я еще делал set-default для @, щас я этого не делал, вроде как лишнее?

root.tar.lzma распаковался с такими же ошибками как и при упаковке

mnt/ssd/@/.__deepin.db
mnt/ssd/@/.check-aur
mnt/ssd/@/.__deepin.lft
mnt/ssd/@/.__deepin.num
mnt/ssd/@/bin
mnt/ssd/@/lib
mnt/ssd/@/lib64
mnt/ssd/@/sbin
mnt/ssd/@/.Trash-1000/
mnt/ssd/@/.Trash-1000/expunged/
mnt/ssd/@/.Trash-1000/info/
mnt/ssd/@/.Trash-1000/files/
mnt/ssd/@/snap
mnt/ssd/@/$RECYCLE.BIN/
mnt/ssd/@/$RECYCLE.BIN/S-1-5-21-846077252-1708685303-1620642486-1000/
mnt/ssd/@/$RECYCLE.BIN/S-1-5-21-846077252-1708685303-1620642486-1000/desktop.ini
tar: Завершение работы с состоянием неисправности из-за возникших ошибок

распаковался с такими же ошибками как и при упаковке

Что значит «с такими же ошибками»? При упаковке могут возникать ошибки чтения; при распаковке тоже, что ли, возникали ошибки чтения?

это норма?

Это весь лог?

и также говорил, что некоторое содержимое нечитаемо

Без понятия, что это могло бы значить при распаковке.

Что значит «с такими же ошибками»?

вот

Это весь лог?

нет я несколько последних строк вставил, home распаковался c такой же фразой в конце,

и также говорил, что некоторое содержимое нечитаемо

извини, это я имел ввиду что в свойствах @ показывает такое.
Итак, я распаковался, зачрутился, обновил /etc/fstab при попытке поставить граб сыпятся ошибки

grub-install /dev/sdb
/etc/default/grub: line 10: /dev/null: No such file or directory
Installing for i386-pc platform.
grub-install: error: cannot find a device for /boot/grub (is /dev mounted?).

is /dev mounted?

[manjaro-mate manjaro]# mount --bind /proc /mnt/ssd/\@/proc/
[manjaro-mate manjaro]# mount --bind /proc /mnt/ssd/\@/dev/
[manjaro-mate manjaro]# mount --bind /proc /mnt/ssd/\@/sys/
[manjaro-mate manjaro]# chroot /mnt/ssd/\@

А здесь, насколько я понял, надо отключить сторонние репы и повторить pacman -Syy

pacman -S mtools os-prober
error: GPGME error: Invalid crypto engine
error: database 'sublime-text' is not valid (invalid or corrupted database (PGP signature))
[manjaro-mate /]# pacman -Syyu              
error: GPGME error: Invalid crypto engine
:: Synchronizing package databases...
 core                     149.1 KiB  1433K/s 00:00 [######################] 100%
 extra                   1754.5 KiB  3.28M/s 00:01 [######################] 100%
 community                  5.3 MiB  2.81M/s 00:02 [######################] 100%
 multilib                 183.7 KiB  1784K/s 00:00 [######################] 100%
 sublime-text            1825.0   B  0.00B/s 00:00 [######################] 100%
 sublime-text.sig         543.0   B  0.00B/s 00:00 [######################] 100%
error: GPGME error: Invalid crypto engine
error: failed to update sublime-text (invalid or corrupted database (PGP signature))
error: failed to synchronize all databases

Окей, я просто скажу, что из твоих отрывочных объяснений со ссылками друг на друга «ну примерно как там было» абсолютно ничего не понятно. Что конкретно делал? Что конкретно получилось?

после корректного pacman -Syy

grub-install /dev/sdb
/etc/default/grub: line 10: /dev/null: No such file or directory
Installing for i386-pc platform.
grub-install: error: cannot find a device for /boot/grub (is /dev mounted?).

[manjaro-mate /]# update-grub 
/usr/share/grub/grub-mkconfig_lib: line 37: /dev/null: No such file or directory
/usr/bin/grub-probe: error: cannot find a device for / (is /dev mounted?).
[manjaro-mate /]# 

pacman -S mtools os-prober
warning: mtools-4.0.23-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (2) mtools-4.0.23-1  os-prober-1.77-1

Total Download Size:   0.20 MiB
Total Installed Size:  0.51 MiB
Net Upgrade Size:      0.01 MiB

:: Proceed with installation? [Y/n] 
error: could not determine cachedir mount point /var/cache/pacman/pkg
error: failed to commit transaction (not enough free disk space)

Чтобы обновить пакеты надо примонтировать @chche, я его подключил mount --bind /proc /mnt/ssd/\@cache/, но ничего не изменилось

Что конкретно делал?

упаковал по отдельности @ и @home в архивы tar.lzma и tar соответственно, упаковка home.tar завершилась корректно, при упаковке @ в root.tar.lzma в конце появилось сообщение tar: Завершение работы с состоянием неисправности из-за возникших ошибок

Что конкретно получилось?

Прим распаковке root.tar.lzma в @ и home.tar в @home выдало в конце tar: Завершение работы с состоянием неисправности из-за возникших ошибок
теперь вот не могу grub восставновить

Прим распаковке root.tar.lzma в @ и home.tar в @home выдало в конце tar: Завершение работы с состоянием неисправности из-за возникших ошибок

Это сообщение эквивалентно «что-то сломалось». На это у меня есть только один ответ: как-нибудь почини.

Полный лог распаковки где? Можно ещё dmesg до кучи.

Полный лог распаковки где?

не думал что понадобится, не сохранил, вот часть, что осталась в терминале https://pastebin.com/uQ3ieHgc

Можно ещё dmesg до кучи.

https://pastebin.com/eK1BKJd2
думаю что с распаковкой уже ничего не сделаешь, мне бы с grub теперь разобраться..

Разобрался, уже пишу из своей системы, Спасибо огромное за помощь! осталось проверить целостность файлов и удалить лишнее, из-за каких-то приколов, восстановленная система занимает места больше чем я забэкапил, было свободно 11 гиг, а теперь свободно 9,2 гиг, с учетом того, что я не бэкапил и не восстанавливал @cache, видимо связано с чем-то подобным

Который состоит из дешевых компонентов.

Ну я потому и написал про "кагбэ брендовый Kingston" :)

Лично у меня самыми беспроблемными SSD были/есть - от Самсунга. Сколько не юзал - все работают без косяков. Хотя цена, конечно, не всегда радует:)