Re: Problems with btrfs

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

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



On 2018年04月29日 00:02, David C. Partridge wrote:
> Here are the dumps you requested.

Sorry, I took wrong dump.

The correct dump would be:
# btrfs inspect dump-tree -t extent <dev>

And you still need to do an extra dump for the final offending tree block.

Considering the extra steps and delays, feel free to use btrfs-restore
to recovery your data.

Thanks,
Qu

> 
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
> Sent: 28 April 2018 15:23
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月28日 22:06, David C. Partridge wrote:
>> Here's the log you asked for ...
>>
>> David
> 
> To dump the offending tree block, you could use the following command:
> 
> # dd if=/dev/mapper/Charon--vg-root of=copy1.dump bs=1 count=16k
> skip=22919544832
> 
> # dd if=/dev/mapper/Charon--vg-root of=copy2.dump bs=1 count=16k
> skip=23456415744
> 
> And attach copy1.img and copy2.img.
> 
> Thanks,
> Qu
> 
>>
>> -----Original Message-----
>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
>> Sent: 28 April 2018 14:54
>> To: David C. Partridge
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月28日 21:38, David C. Partridge wrote:
>>> Oh! doing a private build from source a bit beyond my skill level :(  Are there alternatives like climbing in with a disk editor or is there too much to change?
>>
>> It's possible to only modify that offending tree block.
>> But I can't ensure the safety, thus I recommend to use btrfs-corrupt-block.
>> Since it's not convenient for you, then let's go that way.
>>
>> Please provide the following dump:
>>
>> # btrfs inspect dump-tree -t chunk <device>
>>
>> Then I could calculate the offset on-disk for you to do a binary dump and send that tree block back to me to hand patch it.
>>
>>>
>>> I'm prepared to install a newer version of btrfs-progs if that will fix the problem (assuming I can find a suitable package file).
>>>
>>> I'm assuming that I'll likely also need to update the kernel?
>>
>> Not exactly.
>> If latest btrfs check gives no error after fix, even old kernel should handle it well without problem.
>>
>> But as a generic advice, it's recommended to use latest kernel for btrfs if possible.
>>
>> And currently there is nothing sensitive in the thread (btrfs-inspect.log could contain some filenames, but nothing sensitive right now), so it's better to CC the mail to mail list, just in case some other guy could provide extra help.
>>
>> (Next mail may be after 8~10 hours, as it's bed time for my timezone)
>>
>> Thanks,
>> Qu
>>
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>>> Sent: 28 April 2018 14:25
>>> To: David C. Partridge
>>> Subject: Re: Problems with btrfs
>>>
>>>
>>>
>>> On 2018年04月28日 21:14, David C. Partridge wrote:
>>>> Here's the output from
>>>>
>>>> # btrfs inspect dump-tree /dev/mapper/Charon--vg-root | grep -C 20
>>>> 224304857088
>>>
>>> Located the problem:
>>>
>>> 	item 382 key (224304857088 EXTENT_ITEM 16384) itemoff 14495 itemsize 51
>>> 		extent refs 1 gen 735989 flags TREE_BLOCK
>>> 		tree block key (4401028 UNKNOWN.0 0) level 0
>>>                                 ^^^^^^^^^^^^^^^^^^^
>>> 		shared block backref parent 140827475968
>>>
>>> It could be fixed by special crafted btrfs-corrupt-block tool to handle it.
>>> Although this means you need to compile btrfs-progs by yourself with special branch.
>>>
>>> Before patching btrfs-progs, I'd like to double check if other part is correct.
>>>
>>> Please execute the following command:
>>> # btrfs inspect dump-tree -b 140827475968 /dev/mapper/Charon--vg-root
>>>
>>> If the output is correct, I could start patching btrfs-corrupt-block then.
>>> But please be aware of that, this could only fix the problem found in extent tree, I'm not 100% sure if there will be other problems, as the btrfs-progs is pretty old.
>>>
>>> Thanks,
>>> Qu
>>>
>>>>
>>>> HtH
>>>> David
>>>>
>>>
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]