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

Previous Next

Package: coreutils;

Reported by: "jeff.liu" <jeff.liu <at> oracle.com>

Date: Fri, 7 May 2010 14:16:02 UTC

Severity: normal

Tags: patch

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


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

From: Tao Ma <tao.ma <at> oracle.com>
To: Joel Becker <Joel.Becker <at> oracle.com>
Cc: Sunil Mushran <sunil.mushran <at> oracle.com>, Paul Eggert <eggert <at> CS.UCLA.EDU>,
	bug-coreutils <at> gnu.org, Jim Meyering <jim <at> meyering.net>,
	"jeff.liu" <jeff.liu <at> oracle.com>, Chris Mason <chris.mason <at> oracle.com>
Subject: Re: bug#6131: [PATCH]: fiemap support for efficient sparse file copy
Date: Wed, 16 Jun 2010 21:58:02 +0800

On 06/16/2010 05:03 PM, Joel Becker wrote:
> On Wed, Jun 16, 2010 at 02:57:01PM +0800, jeff.liu wrote:
>> Paul Eggert wrote:
>>> For example, if a fiemap_extent has the FIEMAP_EXTENT_UNWRITTEN flag
>>> set, cp should treat that as a hole, because the extent is all zeros.
>>> (This will greatly help performance in some cases.)  Also, if an input
>>> extent is read and a block of it is found to be zeros, cp should skip
>>> over that block when writing.
>> If FIEMAP_EXTENT_UNWRITTEN flag is set, we can call fallocate(2) against the dest file directly for
>> the performance boost.
>
> 	Nope.  An UNWRITTEN extent is a hole, and the user asked for
> holes.  If cp sees an UNWRITTEN extent it is skipped.
yeah, I agree with this.
The unwritten extent is allocated by the user for the source file. Since 
there is no user say to us that the target also need extra allocation, 
we'd better just leave a hole there. ;)

Regards,
Tao




This bug report was last modified 14 years and 119 days ago.

Previous Next


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