Reynald Posted April 29, 2020 Share Posted April 29, 2020 (edited) Hello all, [Solved], see below, thanks @johnnie.black History I had a problem with "Unmountable BTRFS - No filesystem" on a (almost new, installed few weeks ago) array drive. I solved it with the help of this topic: Basicaly I copy a mirror superblock to the main one. root@Serveur:~# btrfs rescue super-recover -v /dev/mapper/md1 # reported all supers are valid and did not recover root@Serveur:~# btrfs-select-super -s 1 /dev/mapper/md1 # to force using first mirror The drive mounted and, despite data was already there (manually mounted with array in maintenance mode), it has been reconstructed. I then btrfs scrubed it, no errors. I have a inaccessible folder that I can't even delete. Now I still have some unraiparable errors: root@Serveur:~# btrfs check --repair /dev/mapper/md1 enabling repair mode WARNING: Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck can successfully repair all types of filesystem corruption. Eg. some software or hardware bugs can fatally damage a volume. The operation will start in 10 seconds. Use Ctrl-C to stop it. 10 9 8 7 6 5 4 3 2 1 Starting repair. Opening filesystem to check... Checking filesystem on /dev/mapper/md1 UUID: c262207c-8afe-4501-9ed2-522fd075f58d [1/7] checking root items Fixed 0 roots. [2/7] checking extents ref mismatch on [15044599808 131072] extent item 1, found 0 incorrect local backref count on 15044599808 root 5 owner 4996 offset 28704768 found 0 wanted 1 back 0x1730fd0 backref disk bytenr does not match extent record, bytenr=15044599808, ref bytenr=15043026944 backpointer mismatch on [15044599808 131072] owner ref check failed [15044599808 131072] repair deleting extent record: key [15044599808,168,131072] Repaired extent references for 15044599808 ref mismatch on [1099503798605 131072] extent item 0, found 1 unaligned extent rec on [1099503798605 131072] record unaligned extent record on 1099503798605 131072 No device size related problem found [3/7] checking free space cache cache and super generation don't match, space cache will be invalidated [4/7] checking fs roots root 5 inode 4996 errors 4540, bad file extent, file extent discount, nbytes wrong Found file extent holes: start: 28704768, len: 131072 ERROR: errors found in fs roots found 2487837077504 bytes used, error(s) found total csum bytes: 2426215532 total tree bytes: 2765979648 total fs tree bytes: 6717440 total extent tree bytes: 16760832 btree space waste bytes: 283448596 file data blocks allocated: 2485070966784 referenced 2485070966784 I need advice for the next steps to have a clean filesystem please. I see several solutions: there is something more to do to recover with btrfs check --repair I'm not yet aware of use btrfs restore to copy to another drive, then reformat using unbalance to move data elsewhere, (maybe btrfs recover?), then reformat fourth answer 😆, please tell Thank you for any guidance or suggestion ! Take care and stay at home Reynald Edited April 30, 2020 by Reynald Quote Link to comment
JorgeB Posted April 29, 2020 Share Posted April 29, 2020 Best bet is to backup then reformat, some recovery options here if needed. Quote Link to comment
Reynald Posted April 29, 2020 Author Share Posted April 29, 2020 (edited) Thank you @johnnie.black I already read this. As disk is mounted, shall I prefer btrfs restore with array in maintenance mode or unbalance please? Edited April 29, 2020 by Reynald Quote Link to comment
JorgeB Posted April 29, 2020 Share Posted April 29, 2020 If the filesystem is mounted just do a regular copy with your favorite tool. 1 Quote Link to comment
Reynald Posted April 29, 2020 Author Share Posted April 29, 2020 Thank you, I'm unbalancing then. Should I try to btrfs restore before formatting? (I cannot know if there are files missing/still to recover) Quote Link to comment
JorgeB Posted April 29, 2020 Share Posted April 29, 2020 Btrfs restore will save the same files as the ones you can access, unless you get checksum errors copying now there's not much point of doing both. Quote Link to comment
Reynald Posted April 29, 2020 Author Share Posted April 29, 2020 Perfect, I understand now, thank you ! Quote Link to comment
Reynald Posted April 30, 2020 Author Share Posted April 30, 2020 Solved: Here is what I did: First error was reported in the gui after an unclean reboot: Unmountable BTRFS - No filesystem So I mounted array in maintenance mode and did: root@Serveur:~# btrfs rescue super-recover -v /dev/mapper/md1 # reported all supers are valid and did not recover root@Serveur:~# btrfs-select-super -s 1 /dev/mapper/md1 # to force using first mirror The drive mounted but has been reconstructed... After because I still had error reported by btrfs check, I used unBalance to transfert to a healthy drive. I then mounted array in maintenance mode and used: mkdir -p /mnt/disk2/restore && mount /dev/mapper/md2 /mnt/disk2/restore btrfs restore -v /dev/mapper/md1 /mnt/disk2/restore It restored some other broken files. Finally, I unmounted, changed filesystem to another one in GUI so drive got reformatted, and changed back to BTRFS Encrypted, and... voilà ! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.