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

Previous Next

Full log

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

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

On Thu, Jun 10, 2010 at 04:47:23PM -0700, Paul Eggert wrote:
> On 06/09/2010 11:56 PM, jeff.liu wrote:
> 
> > Yeah, I just realized that the behaviour I observed is caused by the delay allocation mechanism of
> > the particular FS.
> 
> If the file system is using delayed allocation, then can
> the fiemap ioctl tell us that a file contains a hole (because nothing has been
> allocated there), but read() would tell us that the file contains nonzero data at the same location
> (because it's sitting in a buffer somewhere)?  If so, we'd need to do something like invoke
> fdatasync() on the file before issuing the fiemap ioctl, to force allocation; or perhaps
> there's another ioctl that will do the allocation without having to actually do a sync.

	I can think of a couple things, like returning an extent record
with a zero block number: "I have an extent here, but I don't have
physical storage."  Or having a filesystem's fiemap call force the
allocation before returning.
	What say we copy linux-ext4 here?

Joel

-- 

"If you took all of the grains of sand in the world, and lined
 them up end to end in a row, you'd be working for the government!"
	- Mr. Interesting

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker <at> oracle.com
Phone: (650) 506-8127

Previous Next

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