On 2020/1/22 上午11:39, Qu Wenruo wrote: > > > On 2020/1/22 上午11:29, Ondřej Váňa wrote: >> Hello! >> I've ran into an issue mounting my /home due to this error: >> `[ 1567.750050] BTRFS critical (device sdb5): corrupt leaf: >> block=135314751488 slot=67 extent bytenr=101613793280 len=134217728 >> invalid generation, have 500462508591547182 expect (0, 222245]` > > This looks like an error caused by older kernel. > > So I guess your fs is created some time ago right? > >> >> Now before seeing the note about contacting the mailing list, I did >> run `btrfs check --repair /dev/sdb5`, though it did not find or >> correct any errors. > > You need btrfs-progs v5.4.1 to "detect" the problem. > But repair needs to be done using this branch: > https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair > >> >> Tried booting older kernels from snapshots and the issue persists. >> >> Now some time between my restarts, the error trying to mount stopped >> displaying the corrupt leaf error and now says there's an unclean >> windows filesystem or just 'mount: /home: wrong fs type, bad option, >> bad superblock on /dev/sdb5, missing codepage or helper program, or >> other error.', but the partition is certainly btrfs. >> >> Here's the required output: >> ``` >> kachna:/oops # uname -a >> Linux kachna.kachna 5.4.10-1-default #1 SMP Thu Jan 9 15:45:45 UTC >> 2020 (556a6fe) x86_64 x86_64 x86_64 GNU/Linux >> kachna:/oops # btrfs --version >> btrfs-progs v5.4 >> kachna:/oops # btrfs fi show >> Label: none uuid: 7dc4b27d-8946-418f-a790-a3eeeac213ba >> Total devices 1 FS bytes used 23.54GiB >> devid 1 size 30.00GiB used 27.55GiB path /dev/sdb3 >> >> Label: 'Home' uuid: 1c0257d6-77ea-4d0c-ad16-2b99114f4e5e >> Total devices 1 FS bytes used 128.05GiB >> devid 1 size 163.47GiB used 140.02GiB path /dev/sdb5 >> >> kachna:/oops # btrfs fi df /home >> ERROR: not a btrfs filesystem: /home >> ``` >> >> I did read through some seemingly related mailing list threads, tried >> running on individual RAM modules to see if one of them could be >> faulty but nothing seems to make a difference. >> >> Is there any way to recover the partition? > > You can just mount use v5.3 kernel without problem. > > Then locate the file owning that extent by: > # btrfs ins logical-resolve 101613793280 </mnt> > > Then remove all involved files if they are not important. > Or just rewrite them with the same content. > > Then the fs should be gone. s/fs/problem/ > > Alternatively, you can try that mentioned branch to repair it, but the > above logical-resolve and delete method should be safer than that > experimental branch. > > Thanks, > Qu > >> >> Cheers! >> >
Attachment:
signature.asc
Description: OpenPGP digital signature
