How to deal with "The chunks in memory can not match the metadata of the fs. Repair failed."?

How to deal with "The chunks in memory can not match the metadata of the fs. Repair failed."?

[Karl-Philipp Richter]

Hi together,
I'm currently encountering another issue with `btrfs rescue 
chunk-recover`. After some seconds of maximal I/O activity, the program 
is idle for some seconds and then prints

     The chunks in memory can not match the metadata of the fs. Repair 
failed.
     Fail to recover the chunk tree.

I don't find any mention of this output except in the source code (this 
is as well the only thing $SEARCH_ENGINE points me to). What is the 
recommended next step? It would be nice to see the situation (The chunks 
in memory can not match the metadata of the fs) or the output mentioned 
in `man btrfs rescue`.

Any help is appreciated.

-Kalle

Re: How to deal with "The chunks in memory can not match the metadata of the fs. Repair failed."?

[Gui Hecheng]

On Mon, 2014-09-15 at 16:59 +0200, Karl-Philipp Richter wrote:
> Hi together,
> I'm currently encountering another issue with `btrfs rescue 
> chunk-recover`. After some seconds of maximal I/O activity, the program 
> is idle for some seconds and then prints
> 
>      The chunks in memory can not match the metadata of the fs. Repair 
> failed.
>      Fail to recover the chunk tree.
> 
> I don't find any mention of this output except in the source code (this 
> is as well the only thing $SEARCH_ENGINE points me to). What is the 
> recommended next step? It would be nice to see the situation (The chunks 
> in memory can not match the metadata of the fs) or the output mentioned 
> in `man btrfs rescue`.
> 
> Any help is appreciated.
> 
> -Kalle

Hi Kalle,
If you are encountering the above msg, it means the chunk tree has some
inconsistent stuff with other trees like device tree & extent tree.
You can specify the '-v' option for chunk-recover to see more details.

And also, the btrfs check cmd may tell more about the story.

Thanks,
Gui


> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to deal with "The chunks in memory can not match the metadata of the fs. Repair failed."?

[Karl-Philipp Richter]

Hi,
Just to give you a really late feedback on this: I got it fixed with
btrfs-progs 3.17.3n on Linux 3.17.6, i.e. `btrfs rescue chunk-recover`
just did the job. Thanks for your advice.

-Kalle

Am 09/16/2014 um 03:46 AM schrieb Gui Hecheng:
> On Mon, 2014-09-15 at 16:59 +0200, Karl-Philipp Richter wrote:
>> Hi together,
>> I'm currently encountering another issue with `btrfs rescue 
>> chunk-recover`. After some seconds of maximal I/O activity, the program 
>> is idle for some seconds and then prints
>>
>>      The chunks in memory can not match the metadata of the fs. Repair 
>> failed.
>>      Fail to recover the chunk tree.
>>
>> I don't find any mention of this output except in the source code (this 
>> is as well the only thing $SEARCH_ENGINE points me to). What is the 
>> recommended next step? It would be nice to see the situation (The chunks 
>> in memory can not match the metadata of the fs) or the output mentioned 
>> in `man btrfs rescue`.
>>
>> Any help is appreciated.
>>
>> -Kalle
> 
> Hi Kalle,
> If you are encountering the above msg, it means the chunk tree has some
> inconsistent stuff with other trees like device tree & extent tree.
> You can specify the '-v' option for chunk-recover to see more details.
> 
> And also, the btrfs check cmd may tell more about the story.
> 
> Thanks,
> Gui
> 
> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>