>>
>> Please try again, and sorry for the inconvenience. Hopes this is the
>> last try.
>
> #sudo ./btrfs-corrupt-block -X /dev/md0
> old offset=131072 len=0
> new offset=0 len=0
My bad, the first fix is bad, leading the bad result.
(And that's why we need to review patches)
Fortunately we have everything we need to manually set the value, no
magic any more.
The only uncertain part is the size.
If mount still fails, dmesg will tell me the size I need.
> Successfully repair tree block at 1894009225216
> # mount -t btrfs -o ro /dev/md0 /mnt/md0/
> mount: /mnt/md0: wrong fs type, bad option, bad superblock on /dev/md0,
> missing codepage or helper program, or other error.
> root@bach:~# dmesg|tail
> ...
> [39342.860715] BTRFS info (device md0): disk space caching is enabled
> [39342.933380] BTRFS info (device md0): bdev /dev/md0 errs: wr 0, rd 0,
> flush 0, corrupt 2181, gen 0
> [39344.197411] BTRFS critical (device md0): corrupt leaf: root=1
> block=1894009225216 slot=30, unexpected item end, have 0 expect 15003
> [39344.197915] BTRFS error (device md0): failed to read block groups: -5
> [39344.248137] BTRFS error (device md0): open_ctree failed
>
> Sorry, I forgot to tell: this and previous attempt were with kernel
> 4.15.0-47-generic.
As long as it can output above message, the kernel version doesn't make
much difference.
> My Ubuntu 18.04 LTS is having enormous problems with
> Kernel 5.0.2 - very long boot; network, login and other services cycling
> trough "start, timeout, fail, stop" again and again, etc. If kernel 5 is
> important I will need time to get it right (maybe even assistance from
> another(?) developer group).
> Actually with 5.0.2 each boot sends me an email about an empty and not
> automatically mounted btrfs filesystem with raid1 profile, consisting
> from two devices (sdb and sdi):
>
> kernel: [ 9.625619] BTRFS: device fsid
> 05bd214a-8961-4165-9205-a5089a65b59b devid 2 transid 832 /dev/sdi
>
> Scrubbing it finishes almost immediately (see below), but during next
> boot the email comes again:
>
> #btrfs scrub status /mnt/b
> scrub status for 05bd214a-8961-4165-9205-a5089a65b59b
> scrub started at Sat Apr 6 10:42:15 2019 and finished after
> 00:00:00
> total bytes scrubbed: 1.51MiB with 0 errors
>
> Should I be worried about it?
You could try btrfs check --readonly and see what's going on.
If btrfs check --readonly is OK, then it should be mostly OK.
Thanks,
Qu
>
> Kind regards,
> Nik.
> --
>
>> Thanks,
>> Qu
>>>
>>> Thank you.
>>> Nik.
>>> --
>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>>>
>>>>> Actually there was one warning during make, I don't know of it is
>>>>> relevant:
>>>>> [CC] check/main.o
>>>>> check/main.c: In function ‘try_repair_inode’:
>>>>> check/main.c:2688:5: warning: ‘ret’ may be used uninitialized in this
>>>>> function [-Wmaybe-uninitialized]
>>>>> if (!ret) {
>>>>> ^
>>>>> check/main.c:2666:6: note: ‘ret’ was declared here
>>>>> int ret;
>>>>> ^~~
>>>>>
>>>>> The previous steps were as follow (output ommited, since nothing
>>>>> unexpected happened):
>>>>> #git clone --single-branch -v -b dirty_fix_for_nik
>>>>> https://github.com/adam900710/btrfs-progs.git
>>>>> #cd btrfs-progs/
>>>>> #./autogen.sh
>>>>> #./configure --disable-documentation --disable-convert
>>>>> #make
>>>>>
>>>>> Did I got the right branch? Or miss any step?
>>>>>
>>>>> Kind regards,
>>>>> Nik.
>>>>> --
>>>>>
>>>>>> If everything goes correctly, it should output something like:
>>>>>> Successfully repaired tree block at 1894009225216
>>>>>> (And please ignore any grammar error in my code)
>>>>>>
>>>>>> After that, please run a "btrfs check --readonly" to ensure no other
>>>>>> bit
>>>>>> flip in your fs.
>>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hope this is ok.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nik.
>>>>>>> -
>>>>>>
>>>>
>>
Attachment:
signature.asc
Description: OpenPGP digital signature
