On Fri, 10 Apr 2015 09:52:34 +1000 Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Thu, Apr 09, 2015 at 10:23:08AM +0100, David Howells wrote: > > NeilBrown <neilb@xxxxxxx> wrote: > > > > > Is there a better way? Could a better way be created? Maybe > > > SEEK_DATA_RELIABLE ?? > > > > fiemap() maybe? > > fiemap is not reliable for mapping holes - it returns extent info, > not whether there is data in a range. i.e. there can be data over a > hole (e.g. delayed allocation) and fiemap will return it as a hole. > cp made this mistake back when fiemap was first introduced, > resulting in corrupt file copies. I assumed from the doco that FIEMAP_EXTENT_DELALLOC would get returned in this case. I guess not? > > SEEK_HOLE/SEEK_DATA is what you want, as they are page cache > coherent, not extent based operations. And, really if you need it to > really be able to find real holes, then a superblock flag might be a > better way of marking filesystems with the required capability. btrfs seems to use the same underlying functionality for both fiemap and SEEK_HOLE/SEEK_DATA... But yes: a new fs_flags flag is probably the go. Thanks, NeilBrown > > Cheers, > > Dave.
Attachment:
pgpTG8f3jZHgq.pgp
Description: OpenPGP digital signature
