bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6131: [PATCH]: fiemap support for efficient sparse file copy


From: Sunil Mushran
Subject: bug#6131: [PATCH]: fiemap support for efficient sparse file copy
Date: Thu, 10 Jun 2010 17:31:57 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4

On 06/10/2010 04:47 PM, 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 guess we'll have to use FIEMAP_FLAG_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.

cp's behavior with active files is undefined. But we know it reads from
offset 0 to MAX. With fiemap it will continue to do the same with the
exception that it will skip reads (and thus writes) depending on the extent
map it gets at the very beginning.

(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.

There is no plan to implement SEEK_HOLE/SEEK_DATA in the kernel.
At most glibc will use fiemap to extend lseek(). BTW, SEEK_HOLE/DATA
also have the same problem with active files.

ccing linux-ext4.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]