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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> CS.UCLA.EDU>
To: "jeff.liu" <jeff.liu <at> oracle.com>
Cc: Sunil Mushran <sunil.mushran <at> oracle.com>, bug-coreutils <at> gnu.org,
	Jim Meyering <jim <at> meyering.net>,
	Joel Becker <Joel.Becker <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 16:47:23 -0700

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.

There's also the issue of copying from a file at the same time that some other process
is writing to it, but that is allowed to produce ill-defined behavior.  I'm more worried
about the case where some other process writes to the source file just before 'cp' starts.

(Sorry, I haven't had time yet to dive into the proposed change; I'm still trying to understand
the environment.)

One other thing: Solaris 10 supports lseek with the SEEK_HOLE and SEEK_DATA options, which
are easier to use and which (as far as I can tell from the manual) shouldn't require anything
fdatasync-ish.  Any objection if I propose support for that too?  It is supposed to work
with ZFS, something I can test here.

Previous Next

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