Re: interest in post-mortem examination of a BTRFS system and improving the btrfs-code?

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6204 bytes --]



On 2019/4/6 下午9:22, Qu Wenruo wrote:
> 
> 
> On 2019/4/6 下午9:20, Nik. wrote:
>>
>>
>> 2019-04-06 11:06, Qu Wenruo:
>>>>>
>>>>> 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.
>>
>> So I gues the next steps were git fetch, make and run again the above
>> two commands:
>>
>> #git fetch
>> From https://github.com/adam900710/btrfs-progs
>>  + c7bfe8cc...a8c26abd dirty_fix_for_nik -> origin/dirty_fix_for_nik
>> (forced update)
> 
> It looks like you haven't checked out to the correct branch.
> 
> You could use command 'git checkout origin/dirty_fix_for_nik' to change
> to the latest branch.

BTW, you could combine the fetch + checkout to 'git pull' directly.

Thanks,
Qu

> 
> Thanks,
> Qu
> 
>> #make
>>     [PY]     libbtrfsutil
>>
>> #./btrfs-corrupt-block -X /dev/md0
>> old offset=0 len=0
>> new offset=0 len=0
>> 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.
>>
>> # dmesg|tail
>> ...
>> [56146.672395] BTRFS info (device md0): disk space caching is enabled
>> [56146.841632] BTRFS info (device md0): bdev /dev/md0 errs: wr 0, rd 0,
>> flush 0, corrupt 2181, gen 0
>> [56148.097242] BTRFS critical (device md0): corrupt leaf: root=1
>> block=1894009225216 slot=30, unexpected item end, have 0 expect 15003
>> [56148.097583] BTRFS error (device md0): failed to read block groups: -5
>> [56148.140137] BTRFS error (device md0): open_ctree failed
>>
>> If the above steps were wrong - please, correct!
>>
>>> 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.
>>
>> Then it seems to be ok, thank you!
>>
>>
>>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]