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