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

PS после первого раза проводил кучу проверок ssd,

Какие?

Ну подыхает значит твой Kingston... Бэкапь и беги за новым кингстоном.

Какие?

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

Ну подыхает значит твой Kingston

если быть точнее, то kingdian)

Бэкапь и беги за новым кингстоном

а как бекапить? в систему не пускает, загрузиться щас не с чего...

попробовал заuрузится со снапшота, та же песня,
вот сделал еще фотку journalctl -xb | grep err

Скопируй файлы и папки командой cp -r в следующий раз, когда файловая система переходит в read-only состояние. На другой диск.

Ну, грубо говоря...

Обычно контроллер SSD посылает ядру сигнал о неисправности диска/исчерпании ячеек и ядро принимает решение перевести ФС в указанный режим для предотвращения ее дальнейшего разрушения.

smart1, smart2 вроде норм, а вот btrfs check --repair 1, 2
судя по выхлопу проблема в btrfs

https://imgur.com/a/nvHeut3

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

У тебя файловая сдохла

это я уже понял, хотелось бы оживить, есть снапшоты, правда они на том же разделе живут, то есть в /.snapshots

прежде чем использовать экзотические ФС

за 1,5 года ни единого разрыва, в чем может быть причина столь специфического поведения?

в чем может быть причина столь специфического поведения?

В кривости btrfs - тут на форуме регулярно появляются топики про различные проблемы с ней, причём почти у всех она ломается «внезапно» (с). Я бы не стал связываться с ФС, которая может встать колом в любой момент. Даже при наличии свежих бэкапов это, как минимум, потеря времени.

kingdian
btrfs

Да ты мастер ходить по граблям.

kingdian
Да ты мастер ходить по граблям.

Ну тут как повезёт, на самом деле. Я в 2015 купил из интереса на али Netac N5m 120 ГБ, он пару лет отпахал на моей машине, а теперь стоит в старом ноутбуке жены под Виндой 7-й. Пока не помер :) При этом у отца типа брендовый Kingston SATA 120 Гб сдох через полтора года.

В кривости btrfs

ясненько
терерь вопрос, могу ли я свои данные с бтр рсинкнуть на раздел hdd с ntfs? а потом перенести на заблаговременно подготовленный ext4 на ссд? (просто у меня дефицит свободного места на харде)

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

Лучше в tar-файл сохрани на свой ntfs-раздел. Если бэкапишь много файлов, то даже быстрее будет, чем просто копировать туда-сюда. Да и права на файлы сохраняться.

имеется такая структура

sudo btrfs subvolume list /mnt/
ID 258 gen 547472 top level 5 path @home
ID 259 gen 547245 top level 5 path @cache
ID 660 gen 547470 top level 5 path @
ID 828 gen 546506 top level 660 path @/.snapshots/2019-07-14--03-50-43-@daily
ID 829 gen 546775 top level 660 path @/.snapshots/2019-07-15--21-53-38-@daily
ID 830 gen 547467 top level 660 path @/.snapshots/2019-07-16--20-47-24-@daily

[br]
допустим @home я забэкаплю такой командой

tar -cvzpf /mnt/HDD/backup.tar.gz -C /mnt/@home

а как обойти снапшоты, которые лежат в @/.snapshots? фс ведь доступна для чтения, делетнуть их вряд ли удастся, а если и удастся, могу что-то повредить, @cache я так понимаю можно не бэкапить?
И да после бэкапа хотелось бы попробовать пофиксить то что имею, htower, RedEyedMan4, t184256 поможете? хотелось бы для себя разобраться где собака порылась, да и для опыта и общества полезно

tar -cvzpf /mnt/HDD/backup.tar.gz -C /mnt/ --exclude=/mnt/@/.snapshots

Снапшоты схожи с каталогами, так что должно сработать.

tar --lzma -cvpf /mnt/HDD/home.tar.lzma -C /mnt/ssd/\@home
tar: Робкий отказ от создания пустого архива
Попробуйте «tar --help» или «tar --usage» для
получения более подробного описания.
[manjaro-mate manjaro]# tar -cvzpf /mnt/HDD/backup.tar.gz -C /mnt/ssd/\@home/
tar: Робкий отказ от создания пустого архива
Попробуйте «tar --help» или «tar --usage» для
получения более подробного описания.

ЧЯДНТ?

убрал -С процесс пошел)

бэкап @ завершился неудачей

/mnt/ssd/@/.snapshots/
tar: /mnt/ssd/@/.snapshots/2019-07-14--03-50-43-@daily: Функция stat завершилась с ошибкой: Ошибка ввода/вывода
tar: /mnt/ssd/@/.snapshots/2019-07-15--21-53-38-@daily: Функция stat завершилась с ошибкой: Ошибка ввода/вывода
tar: /mnt/ssd/@/.snapshots/2019-07-16--20-47-24-@daily: Функция stat завершилась с ошибкой: Ошибка ввода/вывода
/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
tar: Завершение работы с состоянием неисправности из-за возникших ошибок

А я и не заметил про -C :) Пора на боковую...

Бэкапь данные выборочно, если можешь.

Бэкапь данные выборочно, если можешь.

типа /etc в etc.tar, /usr в usr.tar?

я просто хотел сохранить все и потом без переустановки разметить заново диск и вернуть все на место, а потом тольео граб обновить и вуаля...
Ну а вообще в идеале хотелось бы все починить без этих танцев, бэкап как страховка

пробую чекнуть фс, такой выхлоп

btrfs check --repair --check-data-csum /dev/sdb1
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/sdb1
UUID: b79f6a6c-0ce8-4063-b7bb-717507e895a9
[1/7] checking root items
incorrect offsets 12308 12255
incorrect offsets 12308 12255
Fixed 0 roots.
[2/7] checking extents
incorrect offsets 12308 12255
Shifting item nr 78 by 53 bytes in block 56930172928
Shifting item nr 79 by 53 bytes in block 56930172928
Shifting item nr 80 by 53 bytes in block 56930172928
Shifting item nr 81 by 53 bytes in block 56930172928
Shifting item nr 82 by 53 bytes in block 56930172928
Shifting item nr 83 by 53 bytes in block 56930172928
Shifting item nr 84 by 53 bytes in block 56930172928
Shifting item nr 85 by 53 bytes in block 56930172928
Shifting item nr 86 by 53 bytes in block 56930172928
Shifting item nr 87 by 53 bytes in block 56930172928
Shifting item nr 88 by 53 bytes in block 56930172928
Shifting item nr 89 by 53 bytes in block 56930172928
Shifting item nr 90 by 53 bytes in block 56930172928
Shifting item nr 91 by 53 bytes in block 56930172928
Shifting item nr 92 by 53 bytes in block 56930172928
Shifting item nr 93 by 53 bytes in block 56930172928
Shifting item nr 94 by 53 bytes in block 56930172928
Shifting item nr 95 by 53 bytes in block 56930172928
Shifting item nr 96 by 53 bytes in block 56930172928
items overlap, can't fix
check/main.c:4243: fix_item_offset: BUG_ON `ret` triggered, value -5
btrfs(+0x5c2b2)[0x55a82302f2b2]
btrfs(+0x658ff)[0x55a8230388ff]
btrfs(+0x65c80)[0x55a823038c80]
btrfs(+0x668bc)[0x55a8230398bc]
btrfs(cmd_check+0x1384)[0x55a82303deb4]
btrfs(main+0x92)[0x55a822fe60c2]
/usr/lib/libc.so.6(__libc_start_main+0xf3)[0x7f587c3d2ee3]
btrfs(_start+0x2e)[0x55a822fe62ce]
Aborted (core dumped)

походу нужен более свежий образ системы..:?

В тред для помощи призывается intelfx, замеченный в использовании btrfs :)

Первое правило btrfs — запускать btrfs check --repair только после посекторного бэкапа сломанного тома. Оно может сделать ещё хуже (например, упав посередине процесса, что у тебя и произошло).

Том хотя бы в R/O продолжает монтироваться? Забэкапь данные, если ещё этого не сделал, и сноси ФС к чертям.

Вернись на ext4, а про снапшоты забудь. Btrfs сырая.

да

фс монтируется, бэкап смог сделать только @home, на бэкапе @ происходит это, RedEyedMan4 советует @ бэкапить по отдельности

после посекторного бэкапа сломанного тома

это какими средствами делается?

и сноси ФС к чертям

в общем возвращение фс в статус кво невозможен?

и еще, в качестве совета, раз уж мне с вероятностью в 99% придется переустанавливать ось, хотел бы задать такой вопрос. У меня комп умеет в ефи и в легаси, когда ставил систему еще где-то в 2015 то с ефи заморачиваться не стал, что скажете, есть ли смысл или не заморачиваться?

на бэкапе @ происходит это

И что, это весь @? В бэкап ничего не попадает в итоге?

RedEyedMan4 советует @ бэкапить по отдельности

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

это какими средствами делается?

Любыми. Например, dd.

в общем возвращение фс в статус кво невозможен?

Тебе бы сначала данные спасти. Про восстановление самой ФС забудь.

И что, это весь @? В бэкап ничего не попадает в итоге?

бэкап создается, сегодня перепроверил, в сжатом виде(lzma) 11.3 Гб, вот вроде как все основное есть
переживаю, что он некорректно распакуется

Про восстановление самой ФС забудь.

ok

Тебе бы сначала данные спасти.

@home создал, @ то что есть создал, @cache - не обязательно, насколько я понимаю?
Если все верно завтра приступлю к восстановлению
есть ли еще какие-то поводные камни?
ЗЫ. хотел бы на счет бтрфс уточнить, на какой период о ней стоит забывать?

и еще, архив сохранился с жесткими путями типа /mnt/ssd/@/, как его правильно распаковывать, например в / ?

На ближайшие лет 5 забудь про неё. Используй ext4 поверх LVM, если хочется больше гибкости, стабильнее ничего нет пока. А вот ошибки ввода-вывода наталкивают на мысль, что у тебя не с ФС проблема, а с диском. Ты бы его SMART показал.

Ты бы его SMART показал.

уже показывал, в первую очередь смотрел

Используй ext4 поверх LVM, если хочется больше гибкости

можешь дать что-то в этом направлении почитать?

1. бэкапить образ раздела при помощи dd в два разных места и лепишь на них chattr -i для надежности

2. делаешь с последующими их копиями что душе угодно, я бы начал с mount -o ro,subvolid=??? и последующий tar, а параллельно поигрался бы со средствами восстановления btrfs

http://xgu.ru/wiki/LVM

btrfs

Выбрось это поделие. Лучше уж NTFS, чем это.

Как пишут, Kingdian-ы иногда переходят в read only

Как пишут, Kingdian-ы иногда переходят в read only

читал

спасибо!

бэкап создается, сегодня перепроверил, в сжатом виде(lzma) 11.3 Гб, вот вроде как все основное есть

Тогда всё отлично.

переживаю, что он некорректно распакуется

Если создался — распакуется.

@home создал, @ то что есть создал, cache - не обязательно, насколько я понимаю?

Просто смонтируй свою ФС с -o ro,subvol=/ и забэкапь всю точку монтирования. На твоём месте я бы разбирался уже потом, после распаковки на новую ФС.

ЗЫ. хотел бы на счет бтрфс уточнить, на какой период о ней стоит забывать?

Я не говорил «забудь про btrfs». Это всякие истерички говорят, я к ним отношения не имею. Я говорил, что не стоит пытаться восстановить данный конкретный экземпляр btrfs: если ФС продолжает читаться, то гораздо проще забэкапить всё что читается и пересоздать ФС с нуля.

брендовый Kingston SATA

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

Рассмешил мои мамбетки.

RedEyedMan4

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

Просто смонтируй свою ФС с -o ro,subvol=/ и забэкапь всю точку монтирования. На твоём месте я бы разбирался уже потом, после распаковки на новую ФС.

монтировал так mount -o subvolid=0 /dev/sdb1 /mnt, щас еще делаю сжатый образ жд с помощью dd dd if=/dev/sdb bs=8M conv=sync,noerror status=progress | gzip -c > /mnt/HDD/backup.img
на сколько я понимаю, его можно будет потом смонтировать и из него вытащить все необходимое, если можно объясни один момент, dd ведь сохраняет образ жд полностью с учетом структуры поломанной фс и неразмеченного пространства, предполагаю, что я его смонтирую, а потом с помощью rsync всё это дело раскидаю по вновь созданным разделам, интересует вероятность поймать что-то невразумительное.
ну и еще у меня есть все в tar, какой способ корректней?

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

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