bug#6131: [PATCH]: fiemap support for efficient sparse file copy (original) (raw)

[Top][All Lists]

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

From: Jim Meyering
Subject: bug#6131: [PATCH]: fiemap support for efficient sparse file copy
Date: Fri, 11 Jun 2010 16:52:40 +0200

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.

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 SEEKHOLE and SEEKDATA 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.

Sure, having an implementation that also works on ZFS would be welcome. I updated (non-fast-forward) the fiemap-copy branch an hour or so ago.