Btrfs devel - Jan 2013 - [PATCH 0/2] send: Avoid sending disknr==0 and PREALLOC extents when possible

These two patches address the issue of sending unneeded zero data for
disknr==0 and PREALLOC extents.
There is room for additional improvement for PREALLOC extents, but it
requires adding a new command, so for
now this is not addressed.

Please review and comment.

Thanks,
Alex.

Alex Lyakas (2):
  Avoid sending disknr==0 extents in the following cases:     1) full
    send 2) new inode in a diff-send 3) when disknr==0 extents are
    added to the end of an inode
  On a diff-send, avoid sending PREALLOC extents, if the parent root
    has only     PREALLOC extents on an appropriate file range.

 fs/btrfs/send.c |  178 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 172 insertions(+), 6 deletions(-)

--
1.7.9.5
--
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

Hi, Alex
The patches can only solve part of questions, but some like "punch
holes" problems
as Alexander wrote are still unsolved. So I think these patches are unnecessary
if adding new command would help to solve all the questions.

Chen.

On 2013-1-9 4:11, Alex Lyakas wrote:
> These two patches address the issue of sending unneeded zero data for
> disknr==0 and PREALLOC extents.
> There is room for additional improvement for PREALLOC extents, but it
> requires adding a new command, so for
> now this is not addressed.
> 
> Please review and comment.
> 
> Thanks,
> Alex.
> 
> Alex Lyakas (2):
>   Avoid sending disknr==0 extents in the following cases:     1) full
>     send 2) new inode in a diff-send 3) when disknr==0 extents are
>     added to the end of an inode
>   On a diff-send, avoid sending PREALLOC extents, if the parent root
>     has only     PREALLOC extents on an appropriate file range.
> 
>  fs/btrfs/send.c |  178
+++++++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 172 insertions(+), 6 deletions(-)
> 
> --
> 1.7.9.5
> 
--
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

Hi Chen,
thanks for reviewing.

I partially disagree with you. The new command(s) is required when the
code detects a change and wants to communicate this change to the
receive side. My patch addresses the cases when
- no new command is required to communicate the change (patch1)
- there is no change that is needed to be communicated (patch 2)

So even if/when new command is added, my patch still holds, I believe.
However, let''s see what others will comment.

Thanks,
Alex.


On Thu, Jan 10, 2013 at 5:25 AM, Chen Yang <chenyang.fnst@cn.fujitsu.com>
wrote:
> Hi, Alex
> The patches can only solve part of questions, but some like "punch
holes" problems
> as Alexander wrote are still unsolved. So I think these patches are
unnecessary
> if adding new command would help to solve all the questions.
>
> Chen.
>
> On 2013-1-9 4:11, Alex Lyakas wrote:
>> These two patches address the issue of sending unneeded zero data for
>> disknr==0 and PREALLOC extents.
>> There is room for additional improvement for PREALLOC extents, but it
>> requires adding a new command, so for
>> now this is not addressed.
>>
>> Please review and comment.
>>
>> Thanks,
>> Alex.
>>
>> Alex Lyakas (2):
>>   Avoid sending disknr==0 extents in the following cases:     1) full
>>     send 2) new inode in a diff-send 3) when disknr==0 extents are
>>     added to the end of an inode
>>   On a diff-send, avoid sending PREALLOC extents, if the parent root
>>     has only     PREALLOC extents on an appropriate file range.
>>
>>  fs/btrfs/send.c |  178
+++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>  1 file changed, 172 insertions(+), 6 deletions(-)
>>
>> --
>> 1.7.9.5
>>
>
--
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