Re: Btrfs send to send out metadata and data separately

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

At 07/29/2016 09:14 PM, Libor Klepáč wrote:
> Hello,
>
> just a little question on receiver point 0), see bellow
>
> Dne pátek 29. července 2016 20:40:38 CEST, Qu Wenruo napsal(a):
>> Hi Filipe, and maintainers,
>>
>> Receive will do the following thing first before recovering the
>> subvolume/snapshot:
>>
>> 0) Create temporary dir for data extents
>>     Create a new dir with temporary name($data_extent), to put data
>> extents into it.
>
> These are the directories in format "o4095916-21925-0" on receiver side?

That's the temporary dir/file receive creates.

If using send-test(not complied anymore), you will see that that's how 
receive recover files/dirs:

1) mkfile/mkdir with temporary name
2) rename temporary file/dir to its final name

>
> I'm in middle of send/receive and i have over 300 thousand of them already.
> I was always told, that directory with lots of items suffers on performance
> (but i newer used btrfs before :), is that true?

Not completely true.

The fact is even worse, no matter dir or file, if there are too much 
inodes/extents in a *subvolume/snapshot*, it will be slowed down.

Unlike normal fs (ext*/xfs), btrfs put all dir/file info into one 
subvolume tree.

But that's to say, if you design the subvolume layout carefully, which 
means never put too many things into one subvolume, then it should not 
be a big problem though.

>
> Should it be little structured (subdirs based on extent number, for example) ?

Dir and file are sharing the same subvolume/dir tree, so subdir won't help.

But I can create a new subvolume for data extents, and reflink can work 
across subvolumes.
So that's won't cause a big problem though.

Thanks,
Qu

>
> Libor
> N�����r��y���b�X��ǧv�^�)޺{.n�+����{�n�߲)���w*\x1fjg���\x1e�����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f��\x1e�G���h�\x0f�j:+v���w�٥
>