GNU bug report logs - #6131
[PATCH]: fiemap support for efficient sparse file copy

Previous Next

Full log

Message #89 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tao Ma <tao.ma <at> oracle.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Sunil Mushran <sunil.mushran <at> oracle.com>, "jeff.liu" <jeff.liu <at> oracle.com>,
	bug-coreutils <at> gnu.org, Joel Becker <Joel.Becker <at> oracle.com>,
	Chris Mason <chris.mason <at> oracle.com>
Subject: Re: bug#6131: [PATCH]: fiemap support for efficient sparse file copy
Date: Sun, 30 May 2010 22:28:10 +0800

Hi Jim,

On 05/29/2010 12:44 AM, Jim Meyering wrote:
> Tao Ma wrote:
>
>> Hi Jim
>>
>> On 05/27/2010 06:30 PM, Jim Meyering wrote:
>>> jeff.liu wrote:
>>>> This is the revised version, it fixed the fiemap-start offset calculation
>>>> approach to remove it out
>>>> of the 'for (i = 0; i<   fiemap->fm_mapped_extents; i++)' loop.
>>>
>>> Hi Jeff,
>>>
>>> I've included below the state of my local changes.
>>> Unfortunately, with that 5-patch series, there is always a test failure
>>> on F13/ext4.  Maybe someone who knows more about extents can provide an
>>> explanation?
>> Just want to clarify why ocfs2 didn't work here. I guess the reason
>> also works for ext4 since both ext4 and ocfs2 use block group to
>> organize their blocks in the volume.
>
> Hi Tao,
>
> Thank you for the explanation.
> I'm glad to hear that there is no underlying problem.
>
>> I checked the perl test script to create sparse src file, it will
>> create contiguous bytes(around 20-24k) at an interval of around 40k.So
>> in general, these 20-24k should be contiguous. But that does exist
>> some scenario that they could be separately into 2 extents. Consider
>> one block group is used to allocate blocks to this file, when the
>> block group only has 10K left while you are requiring 20K, it will use
>> the left 10K in this group and allocate 10K from another block
>> group. That would become 2 extents since they can't be contiguous.
>
>> So I guess the right step is to check the holes by using filefrag if
>> you prefer this tool and want to make sure cp doesn't copy holes(I get
>
> Do you know of a tool other than filefrag that I could use?
nope.
>
> It looks like a small script could filter filefrag -v output, detect
> split extents and rewrite to make the output match what's expected.
> Probably not worth it, though, since this is already a very fragile test.
yeah, actually I guess what we want is not the extents number but the 
result of whether extents match. So if we can find all the 
pairs(v_cpos, len) both in the src and the target, and there is no extra 
pair in the target, that is good enough. The extents number is really a 
tricky thing and depends on what the internal file system does.
>
> It would be nice to be able to perform the test in non-root
> mode on any of ext4, ocfs2, btrfs, xfs file systems, but for
> now, due to this difference, I can use only the latter two.
I think with the above method we should test ext4 and ocfs2 also. So 
jeff, could you please write a small script to test whether the above 
method work?

Regards,
Tao

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.