GNU bug report logs - #51433
cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Janne Heß <janne+coreutils <at> hess.ooo>,
 51433 <at> debbugs.gnu.org
Subject: Re: bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE
Date: Fri, 29 Oct 2021 19:04:04 -0700

[Message part 1 (text/plain, inline)]

On 10/28/21 13:59, Pádraig Brady wrote:

> I wonder after getting a SEEK_DATA ENXIO, might we correlate
> we really are at end of file by checking SEEK_HOLE also returns ENXIO?

Wouldn't SEEK_HOLE return the current offset, instead of ENXIO? That is, 
if the underlying data structure is wrong and claims that the rest of 
the file is a hole, wouldn't SEEK_HOLE merely repeat that information?

> Perhaps zfs is updating st_blocks async, or perhaps there are
> runs of zeros in these files that a linker or whatever is sparsifying?

Even if st_blocks was out-of-date, that's just a heuristic and the later 
lseeks should still work. I don't think the files contain actual holes.

I don't see an easy workaround for the ZFS bug, unless we want to slow 
down 'cp' for everybody. This really needs to be fixed on the ZFS side.

The attached patch to OpenZFS might work around the bug (I haven't 
tested it; perhaps someone who uses ZFS could give it a try).

[zfs.patch (text/x-patch, attachment)]

Previous Next

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