On 2020/1/22 下午1:13, Ondřej Váňa wrote: > Thank you for the quick response, it has been created a few years ago > indeed, I booted up an older installation I had around and could find a > single file using the 'btrfs ins logical-resolve 101613793280 </mnt>', > removed it and all is in a good shape now. > Is there something I should do to prevent this from happening again? > Such as recreating the filesystem or should it be somehow "updated"? It looks like a bug in much older kernel, so as long as that bug is fixed, you don't need to bother any more. Just to be extra safe, run btrfs check on the fs with v5.4.1 to ensure there is no other similar problems, then you can call it a day. Thanks, Qu > > Thanks again! > > On Tue., Jan. 21, 2020, 19:39 Qu Wenruo <quwenruo.btrfs@xxxxxxx > <mailto:quwenruo.btrfs@xxxxxxx>> 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. > > 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
