Re: Problems with btrfs

[Qu Wenruo]

On 2018年04月29日 17:59, David C. Partridge wrote:
> Here's the correct output - I mistyped inspect so I got the help output 
> instead of the dump-tree!!! 
> 
> David

The archive is corrupted.
Would you mind to upload it google drive/dropbox?

Thanks,
Qu

> 
> -Original Message-
> From: David C. Partridge [mailto:david.partri...@perdrix.co.uk] 
> Sent: 29 April 2018 10:55
> To: 'Qu Wenruo'; 'linux-btrfs@vger.kernel.org'
> Subject: RE: Problems with btrfs
> 
> Yes I did use seek=
> 
> I attach the new dump-tree - it seems very short compared to the last one you 
> requested ???
> 
> Dave
> 
> -Original Message-
> From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] 
> Sent: 29 April 2018 10:36
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月29日 17:20, David C. Partridge wrote:
>> Here is the result of btrfs check after applying the patch
> 
> Doesn't work as expected.
> 
> Did you apply the patched tree block with "seek="?
> 
> If so, please dump extent tree again to verify if the modification is done 
> correct.
> 
> # btrfs inspect dump-tree -t extent 
> 
> Thanks,
> Qu
> 
>>
>> Dave
>> -----Original Message-
>> From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com]
>> Sent: 29 April 2018 09:36
>> To: David C. Partridge
>> Subject: Re: Problems with btrfs
>>
>> Here is the patched binary tree block.
>>
>> You could apply them by the following command (copy1 and copy2 are the same).
>>
>> # dd if=copy1.img of= bs=1 count=16K seek=25942081536 # dd 
>> if=copy1.img of= bs=1 count=16K seek=26478952448
>>
>> And after that, try btrfs check to see if it reports new error.
>>
>> Thanks,
>> Qu
>>
>> On 2018年04月29日 16:24, David C. Partridge wrote:
>>> Attached as requested
>>>
>>> -Original Message-
>>> From: linux-btrfs-ow...@vger.kernel.org 
>>> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Qu Wenruo
>>> Sent: 29 April 2018 03:08
>>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>>> Subject: Re: Problems with btrfs
>>>
>>>
>>>
>>> On 2018年04月29日 09:55, David C. Partridge wrote:
>>>> Not a problem
>>>>
>>>> See attached
>>>
>>> The final binary dump:
>>>
>>> # dd if= of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
>>> dd if= of=/tmp/copy2.img bs=1 count=16K skip=26478952448
>>>
>>> Thanks,
>>> Qu
>>>
> 



signature.asc
Description: OpenPGP digital signature

Re: Problems with btrfs

[Qu Wenruo]

On 2018年04月29日 17:55, David C. Partridge wrote:
> Yes I did use seek=
> 
> I attach the new dump-tree - it seems very short compared to the last one you 
> requested ???

Well, my fault, wrong spell.

# btrfs inspect dump-tree -t extent 

Which should give a lengthy dump.

Thanks,
Qu

> 
> Dave
> 
> -Original Message-
> From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] 
> Sent: 29 April 2018 10:36
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月29日 17:20, David C. Partridge wrote:
>> Here is the result of btrfs check after applying the patch
> 
> Doesn't work as expected.
> 
> Did you apply the patched tree block with "seek="?
> 
> If so, please dump extent tree again to verify if the modification is done 
> correct.
> 
> # btrfs inspect dump-tree -t extent 
> 
> Thanks,
> Qu
> 
>>
>> Dave
>> -Original Message-----
>> From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com]
>> Sent: 29 April 2018 09:36
>> To: David C. Partridge
>> Subject: Re: Problems with btrfs
>>
>> Here is the patched binary tree block.
>>
>> You could apply them by the following command (copy1 and copy2 are the same).
>>
>> # dd if=copy1.img of= bs=1 count=16K seek=25942081536 # dd 
>> if=copy1.img of= bs=1 count=16K seek=26478952448
>>
>> And after that, try btrfs check to see if it reports new error.
>>
>> Thanks,
>> Qu
>>
>> On 2018年04月29日 16:24, David C. Partridge wrote:
>>> Attached as requested
>>>
>>> -----Original Message-
>>> From: linux-btrfs-ow...@vger.kernel.org 
>>> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Qu Wenruo
>>> Sent: 29 April 2018 03:08
>>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>>> Subject: Re: Problems with btrfs
>>>
>>>
>>>
>>> On 2018年04月29日 09:55, David C. Partridge wrote:
>>>> Not a problem
>>>>
>>>> See attached
>>>
>>> The final binary dump:
>>>
>>> # dd if= of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
>>> dd if= of=/tmp/copy2.img bs=1 count=16K skip=26478952448
>>>
>>> Thanks,
>>> Qu
>>>
> 



signature.asc
Description: OpenPGP digital signature

RE: Problems with btrfs

[David C. Partridge]

Yes I did use seek=

I attach the new dump-tree - it seems very short compared to the last one you 
requested ???

Dave

-Original Message-
From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] 
Sent: 29 April 2018 10:36
To: David C. Partridge; linux-btrfs@vger.kernel.org
Subject: Re: Problems with btrfs



On 2018年04月29日 17:20, David C. Partridge wrote:
> Here is the result of btrfs check after applying the patch

Doesn't work as expected.

Did you apply the patched tree block with "seek="?

If so, please dump extent tree again to verify if the modification is done 
correct.

# btrfs inspect dump-tree -t extent 

Thanks,
Qu

> 
> Dave
> -Original Message-
> From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com]
> Sent: 29 April 2018 09:36
> To: David C. Partridge
> Subject: Re: Problems with btrfs
> 
> Here is the patched binary tree block.
> 
> You could apply them by the following command (copy1 and copy2 are the same).
> 
> # dd if=copy1.img of= bs=1 count=16K seek=25942081536 # dd 
> if=copy1.img of= bs=1 count=16K seek=26478952448
> 
> And after that, try btrfs check to see if it reports new error.
> 
> Thanks,
> Qu
> 
> On 2018年04月29日 16:24, David C. Partridge wrote:
>> Attached as requested
>>
>> -Original Message-
>> From: linux-btrfs-ow...@vger.kernel.org 
>> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Qu Wenruo
>> Sent: 29 April 2018 03:08
>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月29日 09:55, David C. Partridge wrote:
>>> Not a problem
>>>
>>> See attached
>>
>> The final binary dump:
>>
>> # dd if= of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
>> dd if= of=/tmp/copy2.img bs=1 count=16K skip=26478952448
>>
>> Thanks,
>> Qu
>>



btrfs-dump-tree1.log
Description: Binary data

Re: Problems with btrfs

[Qu Wenruo]

On 2018年04月29日 17:20, David C. Partridge wrote:
> Here is the result of btrfs check after applying the patch

Doesn't work as expected.

Did you apply the patched tree block with "seek="?

If so, please dump extent tree again to verify if the modification is
done correct.

# btrfs inspect dump-tree -t extent 

Thanks,
Qu

> 
> Dave
> -Original Message-
> From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] 
> Sent: 29 April 2018 09:36
> To: David C. Partridge
> Subject: Re: Problems with btrfs
> 
> Here is the patched binary tree block.
> 
> You could apply them by the following command (copy1 and copy2 are the same).
> 
> # dd if=copy1.img of= bs=1 count=16K seek=25942081536 # dd 
> if=copy1.img of= bs=1 count=16K seek=26478952448
> 
> And after that, try btrfs check to see if it reports new error.
> 
> Thanks,
> Qu
> 
> On 2018年04月29日 16:24, David C. Partridge wrote:
>> Attached as requested
>>
>> -Original Message-
>> From: linux-btrfs-ow...@vger.kernel.org 
>> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Qu Wenruo
>> Sent: 29 April 2018 03:08
>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月29日 09:55, David C. Partridge wrote:
>>> Not a problem
>>>
>>> See attached
>>
>> The final binary dump:
>>
>> # dd if= of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
>> dd if= of=/tmp/copy2.img bs=1 count=16K skip=26478952448
>>
>> Thanks,
>> Qu
>>



signature.asc
Description: OpenPGP digital signature

RE: Problems with btrfs

[David C. Partridge]

Here is the result of btrfs check after applying the patch

Dave
-Original Message-
From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] 
Sent: 29 April 2018 09:36
To: David C. Partridge
Subject: Re: Problems with btrfs

Here is the patched binary tree block.

You could apply them by the following command (copy1 and copy2 are the same).

# dd if=copy1.img of= bs=1 count=16K seek=25942081536 # dd if=copy1.img 
of= bs=1 count=16K seek=26478952448

And after that, try btrfs check to see if it reports new error.

Thanks,
Qu

On 2018年04月29日 16:24, David C. Partridge wrote:
> Attached as requested
> 
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org 
> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Qu Wenruo
> Sent: 29 April 2018 03:08
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月29日 09:55, David C. Partridge wrote:
>> Not a problem
>>
>> See attached
> 
> The final binary dump:
> 
> # dd if= of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
> dd if= of=/tmp/copy2.img bs=1 count=16K skip=26478952448
> 
> Thanks,
> Qu
> 


btrfs-check1.log
Description: Binary data

Re: Problems with btrfs

[Qu Wenruo]

On 2018年04月29日 09:55, David C. Partridge wrote:
> Not a problem
> 
> See attached

The final binary dump:

# dd if= of=/tmp/copy1.img bs=1 count=16K skip=25942081536
# dd if= of=/tmp/copy2.img bs=1 count=16K skip=26478952448

Thanks,
Qu

> 
> 
> -Original Message-
> From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] 
> Sent: 29 April 2018 02:35
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> 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 
> 
> 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.bt...@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.bt...@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 
>>>
>>> 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.bt...@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
>>>>>
>>>>
>>>
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: Problems with btrfs

[Qu Wenruo]

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 

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.bt...@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.bt...@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 
>>
>> 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.bt...@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
>>>>
>>>
>>
> 



signature.asc
Description: OpenPGP digital signature

RE: Problems with btrfs

[David C. Partridge]

Here are the dumps you requested.

-Original Message-
From: Qu Wenruo [mailto:quwenruo.bt...@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.bt...@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 
> 
> 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.bt...@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
>>>
>>
> 



copy1.img
Description: Binary data


copy2.img
Description: Binary data

Re: Problems with btrfs

[Qu Wenruo]

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.bt...@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 
> 
> 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.bt...@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
>>>
>>
> 



signature.asc
Description: OpenPGP digital signature

RE: Problems with btrfs

[David C. Partridge]

Here's the log you asked for ...

David

-Original Message-
From: Qu Wenruo [mailto:quwenruo.bt...@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 

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.bt...@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
>>
> 



btrfs-dump-chunk.log
Description: Binary data

Re: Problems with btrfs

[Chris Murphy]

On Fri, Apr 27, 2018 at 6:20 PM, Qu Wenruo  wrote:
>
>
> On 2018年04月28日 02:38, David C. Partridge wrote:
>> I'm running Ubuntu 16.04.  I rebooted my server today as it wasn't
>> responding.
>>
>> When I rebooted the root FS was read only.
>>
>> I booted a live Ubuntu CD and checked the drive with the results shown in
>> attachment btrfs-check.log.
>>
>> The error was still there after completing the btrfs check --repair :( And
>> when I deleted some old subvolumes from there after that the filesystem went
>> read-only with a bunch errors in dmesg which are in the attached file
>> btrfs-dmesg-errs.log.
>>
>> Of course my last backup was longer ago than I like to think about. Though I
>> could restore back to about 8 months ago, I'd very much prefer not to ...
>>
>> On my bootable CD the Kernel is 4.18.3 and btrfs-progs is 4.7.3-1
>
> Hello time traveler. :)
> Or it's just 4.16.3.

4.8.13 actually according to the dmesg

The problem might have been setup by this problem (and fix in later kernels)
https://patchwork.kernel.org/patch/5449291/

Question if it's an SSD and what the mount options are.



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

Re: Problems with btrfs

[Qu Wenruo]

On 2018年04月28日 02:38, David C. Partridge wrote:
> I'm running Ubuntu 16.04.  I rebooted my server today as it wasn't
> responding.
> 
> When I rebooted the root FS was read only.
> 
> I booted a live Ubuntu CD and checked the drive with the results shown in
> attachment btrfs-check.log.
> 
> The error was still there after completing the btrfs check --repair :( And
> when I deleted some old subvolumes from there after that the filesystem went
> read-only with a bunch errors in dmesg which are in the attached file
> btrfs-dmesg-errs.log.
> 
> Of course my last backup was longer ago than I like to think about. Though I
> could restore back to about 8 months ago, I'd very much prefer not to ...
> 
> On my bootable CD the Kernel is 4.18.3 and btrfs-progs is 4.7.3-1

Hello time traveler. :)
Or it's just 4.16.3.

Btrfs-progs is a little old, and it is not recommended to execute btrfs
check --repair until you know that the problem is.

Fortunately it doesn't cause further damage, although it doesn't fix it
neither.

The offending tree block is 224304857088, please dump the following info
(using latest btrfs-progs if possible)

# btrfs inspect dump-tree -b 224304857088 /dev/mapper/Charon--vg-root
# btrfs inpsect dump-tree /dev/mapper/Charon--vg-root | grep -C 20

Thanks,
Qu

> 
> HELP!!!
> 
> If do have enough space to copy stuff off the root volume but I think I'll
> need hand holding through the recovery process.
> 
> The volume has sub-volumes called @ and @home which are mounted as / and
> /home respectively. 
> 
> Thanks
> David
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: problems with btrfs filesystem loading

[Michał Zegan]

That seems to do the trick, thanks

W dniu 29.12.2016 o 17:53, Roman Mamedov pisze:
> On Thu, 29 Dec 2016 16:42:09 +0100
> Michał Zegan  wrote:
> 
>> I have odroid c2, processor architecture aarch64, linux kernel from
>> master as of today from http://github.com/torwalds/linux.git.
>> It seems that the btrfs module cannot be loaded. The only thing that
>> happens is that after modprobe i see:
>> modprobe: can't load module btrfs (kernel/fs/btrfs/btrfs.ko.gz): unknown
>> symbol in module, or unknown parameter
>> No errors in dmesg, like I have ignore_loglevel in kernel cmdline and no
>> logs in console appear except logs for loading dependencies like xor
>> module, but that is probably not important.
>> The kernel has been recompiled few minutes ago from scratch, the only
>> thing left was .config file. What is that? other modules load correctly
>> from what I can see.
> 
> In the past there's been some trouble with crc32 dependencies:
> https://www.spinics.net/lists/linux-btrfs/msg32104.html
> Not sure if that's relevant anymore, but in any case, check if you have
> crc32-related stuff either built-in or compiled as modules, if latter, try
> loading those before btrfs (/lib/modules/*/kernel/crypto/crc32*)
> 



signature.asc
Description: OpenPGP digital signature

Re: problems with btrfs filesystem loading

[Roman Mamedov]

On Thu, 29 Dec 2016 16:42:09 +0100
Michał Zegan  wrote:

> I have odroid c2, processor architecture aarch64, linux kernel from
> master as of today from http://github.com/torwalds/linux.git.
> It seems that the btrfs module cannot be loaded. The only thing that
> happens is that after modprobe i see:
> modprobe: can't load module btrfs (kernel/fs/btrfs/btrfs.ko.gz): unknown
> symbol in module, or unknown parameter
> No errors in dmesg, like I have ignore_loglevel in kernel cmdline and no
> logs in console appear except logs for loading dependencies like xor
> module, but that is probably not important.
> The kernel has been recompiled few minutes ago from scratch, the only
> thing left was .config file. What is that? other modules load correctly
> from what I can see.

In the past there's been some trouble with crc32 dependencies:
https://www.spinics.net/lists/linux-btrfs/msg32104.html
Not sure if that's relevant anymore, but in any case, check if you have
crc32-related stuff either built-in or compiled as modules, if latter, try
loading those before btrfs (/lib/modules/*/kernel/crypto/crc32*)

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

Re: Problems with "btrfs dev remove" of dead disk

[Anand Jain]

Feb 14 18:30:21 specialbrew kernel: [27576201.178630] BTRFS: bdev /dev/sdh 
errs: wr 128, rd 8, flush 2, corrupt 0, gen 0
Feb 14 18:30:21 specialbrew kernel: [27576201.309583] BTRFS: lost page write 
due to I/O error on /dev/sdh
Feb 14 18:30:21 specialbrew kernel: [27576201.315761] BTRFS: bdev /dev/sdh 
errs: wr 129, rd 8, flush 2, corrupt 0, gen 0
Feb 14 18:30:21 specialbrew kernel: [27576201.322086] BTRFS: lost page write 
due to I/O error on /dev/sdh

…and those BTRFS: messages continue now even though the system no
longer has a /dev/sdh.


   You need the patch set
  [PATCH 00/15] btrfs: Hot spare and Auto replace

   which includes the patch required here.
[PATCH 07/15] btrfs: introduce device dynamic state transition to 
offline or failed


  and this will take care of stopping the IO when disk fails.


Now:

$ sudo btrfs fi sh /srv/tank
Label: 'tank'  uuid: 472ee2b3-4dc3-4fc1-80bc-5ba967069ceb
 Total devices 6 FS bytes used 1.57TiB
 devid3 size 1.82TiB used 383.00GiB path /dev/sdg
 devid4 size 1.82TiB used 384.00GiB path /dev/sdf
 devid5 size 2.73TiB used 1.25TiB path /dev/sdk
 devid6 size 1.82TiB used 347.00GiB path /dev/sdj
 devid7 size 2.73TiB used 464.00GiB path /dev/sde
 *** Some devices missing


 btrfs progs has a code to fabricate missing in the user land
 instead of obtaining from the kernel.
 ---
 commit 206efb60cbe3049e0d44c6da3c1909aeee18f813
btrfs-progs: Add missing devices check for mounted btrfs.
 ---

 So I recommend to use 'btrfs fi show -m', which I guess in your
 case shall not show that devid 2 is missing. Because without
 the kernel patch
   [PATCH 07/15] btrfs: introduce device dynamic state transition to 
offline or failed

 Kernel won't make that (online to offline/failed) transitions at all.

 Current workaround to tell kernel that a device is missing is only
 by .. unmount and mount (not remount (bug)) which is a kind of
 (enterprise unacceptable) workaround. Sorry about that.



$ sudo btrfs dev usage /srv/tank


::


/dev/sdh, ID: 2
Device size:   0.00B
Data,RAID1:383.00GiB
Metadata,RAID1:  1.00GiB
System,RAID1:   32.00MiB
Unallocated: 1.44TiB


 Yep kernel does not know that device is missing. That
 part of the code is in the patch to be integrated as above.


So, ideally I'd like to remove the missing device sdh (id 2) to have
redundant copies of the data until I can insert a new drive. But
"remove" doesn't seem to want to work:




$ sudo btrfs dev remove /dev/sdh /srv/tank
ERROR: not a block device: /dev/sdh
$ sudo btrfs dev remove 2 /srv/tank
ERROR: not a block device: 2
$ btrfs --version
btrfs-progs v4.4


 Since now device is removed. So only option is to use devid
 if you want to remove/delete. but it needs the patch.
   [PATCH 0/7] Introduce device delete by devid
 I think this is being integrated into 4.5.x (needs both kernel
 and progs patches).


 If you happen to try any of these patches, please consider to
 post results.



I expect my kernel might be too old as it is a Debian backports
version on wheezy (linux-image-3.16.0-0.bpo.4-amd64
3.16.7-ckt20-1+deb8u3~bpo70+1).

If I upgrade the kernel then should one of those remove commands
above work?




I would rather not reboot just now if I can achieve redundancy in
some other way. Would a rebalance like:

$ sudo btrfs balance -f -v -sdevid=2 -mdevid=2 /srv/tank

reconstruct redundant copies elsewhere?


 No. Please don't do that. It would aggravate the IO errors and
 disk will never be removed from the kernel.

 I suggest reboot if its btrfs root or btrfs is not a kernel module,
 otherwise
 umount
 modprobe -r btrfs (removes stale device entries)
 btrfs dev scan
 mount

 Now 'btrfs fi show -m' should show device id 2 missing.
 So now either you may replace devid2 or delete devid 2 based
 on your business data protection needs.

 Kindly note. If you are trying the hot spare and auto replace patches,
 in this context after the reboot, the device id will be identified
 as missing. And Not failed. So the auto replace won't trigger
 the replace if you have a spare device. This is as designed.



With this btrfs-progs and kernel version, will a later "btrfs
replace start -r /dev/sdh /dev/sdl" work without me rebooting into a
newer kernel, even though /dev/sdh doesn't exist as a device to the
kernel right now?


 Yes you can consider this, without needing to reboot, however the
 command will be
   btrfs replace start -r 2 /dev/sdl /btrfs

Thanks, Anand



Any information/advice appreciated.

Cheers,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@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 majord...@vger.kernel.org
More majordomo info at  

Re: Problems with "btrfs dev remove" of dead disk

[Andy Smith]

Hi Chris,

On Sun, Feb 14, 2016 at 04:49:29PM -0700, Chris Murphy wrote:
> On Sun, Feb 14, 2016 at 2:55 PM, Andy Smith  wrote:
> > $ sudo btrfs dev remove /dev/sdh /srv/tank
> > ERROR: not a block device: /dev/sdh
> 
> 
> Since now it's a missing device, it should be
> 
> sudo btrfs device remove missing /srv/tank

$ sudo btrfs device remove missing /srv/tank
ERROR: error removing device 'missing': no missing devices found to remove

> But I'm not sure if this works when the volume is not already mounted
> degraded.

I have now done:

# mount -oremount,degraded /srv/tank 

and tried again, but it produces the same response ("mount" now does
show "degraded" as one of the mount flags, however).

I have not yet tried completely unmounting it and mounting it again.

> it really doesn't make sense to me you'd want to increase risk of
> more Btrfs problems when such known things are now fixed. Consider
> 4.1.15 if you want a stable long term yet currently supportable
> kernel.

It is inconvenient to reboot just now, so if I'm able to fix things
without doing so (e.g. by balance or replace) then I would like to.

If that won't be possible then I will of course boot into a newer
kernel at the same time.

If I end up booting into 4.1.15 then it should be possible to mount
degraded and remove missing?

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

Re: Problems with "btrfs dev remove" of dead disk

[Chris Murphy]

On Sun, Feb 14, 2016 at 2:55 PM, Andy Smith  wrote:

>
> So, ideally I'd like to remove the missing device sdh (id 2) to have
> redundant copies of the data until I can insert a new drive. But
> "remove" doesn't seem to want to work:
>
> $ sudo btrfs dev remove /dev/sdh /srv/tank
> ERROR: not a block device: /dev/sdh


Since now it's a missing device, it should be

sudo btrfs device remove missing /srv/tank

But I'm not sure if this works when the volume is not already mounted
degraded. There is no automatic degraded mechanism yet. I think even
newer than 4.4 is needed plus a patch.

http://www.spinics.net/lists/linux-btrfs/msg51912.html



> With this btrfs-progs and kernel version, will a later "btrfs
> replace start -r /dev/sdh /dev/sdl" work without me rebooting into a
> newer kernel, even though /dev/sdh doesn't exist as a device to the
> kernel right now?
>
> Any information/advice appreciated.

On the one hand, the rebuild doesn't change any fs features and
therefore a device rebuilt with e.g. kernel 4.4, should then read fine
later if you go back to 3.16. On the other hand, there's hundreds of
bug fixes, many thousands of insertions and deletions in Btrfs since
then, so it really doesn't make sense to me you'd want to increase
risk of more Btrfs problems when such known things are now fixed.
Consider 4.1.15 if you want a stable long term yet currently
supportable kernel.


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

Re: problems with btrfs send / restore

[Stefan Priebe - Profihost AG]

Am 15.10.2012 22:14, schrieb Alex Lyakas:

Stefan,
the second issue you're seeing was discussed here:
http://www.spinics.net/lists/linux-btrfs/msg19672.html

You can apply the patch I sent there meanwhile, but as Miao pointed
out, I will need to make a better patch (hope will do it soon,
together with this one).


ah OK thanks. So i hope we'll see an updated btrfs-progs git repo soon ;-)

Thanks!

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

Re: problems with btrfs send / restore

[Miao Xie]

On  thu, 11 Oct 2012 21:54:48 +0200, Stefan Priebe wrote:
 Am 11.10.2012 21:43, schrieb David Sterba:
 On Thu, Oct 11, 2012 at 09:33:54PM +0200, Stefan Priebe wrote:
 [server: /btrfs/target]# btrfs send -i /btrfs/src/\@snapshot/1
 /btrfs/src/\@snapshot/2 | btrfs receive /btrfs/target/\@snapshot/
 At subvol /btrfs/src/@snapshot/2
 At subvol 2
 ERROR: failed to open /btrfs/target/@snapshot/@snapshot/1/test.tar. No such 
 file or directory
^^^

 I wonder if this is the ghost snapshot dir entry that Miao fixed. Did
 somehow get into the 'send' stream and confused the receive side.

 david
 
 i missed two facts:
 1.) vanilla kernel 3.6.1
 2.) latest btrfs tools git (cloned at 10/10/2012)

Sorry, I can not reproduce this problem, could you send me the detailed steps?

Thanks
Miao

 
 Stefan
 -- 
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problems with btrfs send / restore

[Stefan Priebe]

Am 15.10.2012 12:16, schrieb Miao Xie:

On  thu, 11 Oct 2012 21:54:48 +0200, Stefan Priebe wrote:

Am 11.10.2012 21:43, schrieb David Sterba:

On Thu, Oct 11, 2012 at 09:33:54PM +0200, Stefan Priebe wrote:

[server: /btrfs/target]# btrfs send -i /btrfs/src/\@snapshot/1
/btrfs/src/\@snapshot/2 | btrfs receive /btrfs/target/\@snapshot/
At subvol /btrfs/src/@snapshot/2
At subvol 2
ERROR: failed to open /btrfs/target/@snapshot/@snapshot/1/test.tar. No such 
file or directory

^^^

I wonder if this is the ghost snapshot dir entry that Miao fixed. Did
somehow get into the 'send' stream and confused the receive side.

david


i missed two facts:
1.) vanilla kernel 3.6.1
2.) latest btrfs tools git (cloned at 10/10/2012)


Sorry, I can not reproduce this problem, could you send me the detailed steps?


mhm there is nothing special. But i try to provide more information / a 
small howto:


# mount |grep btrfs
/dev/sdb on /btrfs/src type btrfs (rw)
/dev/sdc on /btrfs/target type btrfs (rw)

# btrfs subvolume list /btrfs/target/
# btrfs subvolume list /btrfs/src/
ID 277 top level 5 path @snapshot/1
ID 278 top level 5 path @snapshot/2
ID 288 top level 5 path @snapshot/3

# btrfs send /btrfs/src/\@snapshot/1 | btrfs receive 
/btrfs/target/\@snapshot/

At subvol /btrfs/src/@snapshot/1
At subvol 1
#

Now i was trying to send an incremental snapshot:
# btrfs send -i /btrfs/src/\@snapshot/1 /btrfs/src/\@snapshot/2 | btrfs 
receive /btrfs/target/\@snapshot/

At subvol /btrfs/src/@snapshot/2
At subvol 2
ERROR: failed to open /btrfs/target/@snapshot/@snapshot/1/test.tar. No 
such file or directory

#

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

Re: problems with btrfs send / restore

[Alex Lyakas]

Hi Stefan,

Is /btrfs/target/\@snapshot/ a subvolume or a directory?

can you pls try the patch that I posted here:
http://www.spinics.net/lists/linux-btrfs/msg19583.html

I feel that you're hitting a similar issue here. Before you apply the
patch, please verify that you have /etc/mtab on your system (I will
make a more formal patch later).

Thanks,
Alex.


On Mon, Oct 15, 2012 at 9:21 PM, Stefan Priebe s.pri...@profihost.ag wrote:
 Am 15.10.2012 12:16, schrieb Miao Xie:

 On  thu, 11 Oct 2012 21:54:48 +0200, Stefan Priebe wrote:

 Am 11.10.2012 21:43, schrieb David Sterba:

 On Thu, Oct 11, 2012 at 09:33:54PM +0200, Stefan Priebe wrote:

 [server: /btrfs/target]# btrfs send -i /btrfs/src/\@snapshot/1
 /btrfs/src/\@snapshot/2 | btrfs receive /btrfs/target/\@snapshot/
 At subvol /btrfs/src/@snapshot/2
 At subvol 2
 ERROR: failed to open /btrfs/target/@snapshot/@snapshot/1/test.tar. No
 such file or directory

 ^^^

 I wonder if this is the ghost snapshot dir entry that Miao fixed. Did
 somehow get into the 'send' stream and confused the receive side.

 david


 i missed two facts:
 1.) vanilla kernel 3.6.1
 2.) latest btrfs tools git (cloned at 10/10/2012)


 Sorry, I can not reproduce this problem, could you send me the detailed
 steps?


 mhm there is nothing special. But i try to provide more information / a
 small howto:

 # mount |grep btrfs
 /dev/sdb on /btrfs/src type btrfs (rw)
 /dev/sdc on /btrfs/target type btrfs (rw)

 # btrfs subvolume list /btrfs/target/
 # btrfs subvolume list /btrfs/src/
 ID 277 top level 5 path @snapshot/1
 ID 278 top level 5 path @snapshot/2
 ID 288 top level 5 path @snapshot/3

 # btrfs send /btrfs/src/\@snapshot/1 | btrfs receive
 /btrfs/target/\@snapshot/
 At subvol /btrfs/src/@snapshot/1
 At subvol 1
 #

 Now i was trying to send an incremental snapshot:

 # btrfs send -i /btrfs/src/\@snapshot/1 /btrfs/src/\@snapshot/2 | btrfs
 receive /btrfs/target/\@snapshot/
 At subvol /btrfs/src/@snapshot/2
 At subvol 2
 ERROR: failed to open /btrfs/target/@snapshot/@snapshot/1/test.tar. No such
 file or directory
 #

 Greets,

 Stefan
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problems with btrfs send / restore

[Stefan Priebe]

Am 15.10.2012 21:42, schrieb Alex Lyakas:

Is /btrfs/target/\@snapshot/ a subvolume or a directory?

A simple directory.


can you pls try the patch that I posted here:
http://www.spinics.net/lists/linux-btrfs/msg19583.html

I feel that you're hitting a similar issue here. Before you apply the
patch, please verify that you have /etc/mtab on your system (I will
make a more formal patch later).


With your patch it works FINE!! Great!

Another problem i'm seeing is:
# btrfs send -i /btrfs/src/\@snapshot/1 /btrfs/src/\@snapshot/2 | btrfs 
receive /btrfs/target/\@snapshot/

At subvol /btrfs/src/@snapshot/2
ERROR: Failed to lookup path for root 0 - No such file or directory
ERROR: unable to resolve path for root 350

Then i have to wait some seconds and the same command works fine. I see 
the same with btrfs subvolume list PATH


and it is unrelated to your patch.

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

Re: problems with btrfs send / restore

[Alex Lyakas]

Stefan,
the second issue you're seeing was discussed here:
http://www.spinics.net/lists/linux-btrfs/msg19672.html

You can apply the patch I sent there meanwhile, but as Miao pointed
out, I will need to make a better patch (hope will do it soon,
together with this one).

Thanks,
Alex.


On Mon, Oct 15, 2012 at 10:06 PM, Stefan Priebe s.pri...@profihost.ag wrote:
 Am 15.10.2012 21:42, schrieb Alex Lyakas:

 Is /btrfs/target/\@snapshot/ a subvolume or a directory?

 A simple directory.


 can you pls try the patch that I posted here:
 http://www.spinics.net/lists/linux-btrfs/msg19583.html

 I feel that you're hitting a similar issue here. Before you apply the
 patch, please verify that you have /etc/mtab on your system (I will
 make a more formal patch later).


 With your patch it works FINE!! Great!

 Another problem i'm seeing is:

 # btrfs send -i /btrfs/src/\@snapshot/1 /btrfs/src/\@snapshot/2 | btrfs
 receive /btrfs/target/\@snapshot/
 At subvol /btrfs/src/@snapshot/2
 ERROR: Failed to lookup path for root 0 - No such file or directory
 ERROR: unable to resolve path for root 350

 Then i have to wait some seconds and the same command works fine. I see the
 same with btrfs subvolume list PATH

 and it is unrelated to your patch.

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

Re: problems with btrfs send / restore

[David Sterba]

On Thu, Oct 11, 2012 at 09:33:54PM +0200, Stefan Priebe wrote:
 [server: /btrfs/target]# btrfs send -i /btrfs/src/\@snapshot/1
 /btrfs/src/\@snapshot/2 | btrfs receive /btrfs/target/\@snapshot/
 At subvol /btrfs/src/@snapshot/2
 At subvol 2
 ERROR: failed to open /btrfs/target/@snapshot/@snapshot/1/test.tar. No such 
 file or directory
  ^^^

I wonder if this is the ghost snapshot dir entry that Miao fixed. Did
somehow get into the 'send' stream and confused the receive side.

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

Re: problems with btrfs send / restore

[Stefan Priebe]

Am 11.10.2012 21:43, schrieb David Sterba:

On Thu, Oct 11, 2012 at 09:33:54PM +0200, Stefan Priebe wrote:

[server: /btrfs/target]# btrfs send -i /btrfs/src/\@snapshot/1
/btrfs/src/\@snapshot/2 | btrfs receive /btrfs/target/\@snapshot/
At subvol /btrfs/src/@snapshot/2
At subvol 2
ERROR: failed to open /btrfs/target/@snapshot/@snapshot/1/test.tar. No such 
file or directory

   ^^^

I wonder if this is the ghost snapshot dir entry that Miao fixed. Did
somehow get into the 'send' stream and confused the receive side.

david


i missed two facts:
1.) vanilla kernel 3.6.1
2.) latest btrfs tools git (cloned at 10/10/2012)

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