On Wed, Sep 20, 2017 at 04:41:30PM +0200, Christoph Hellwig wrote: > On Wed, Sep 20, 2017 at 09:23:18AM -0400, Brian Foster wrote: > > I couldn't quite tell from your previous response, so just to be sure... > > is the expectation to set BMV_OF_LAST on the last real extent of the > > file, even though we might report a hole entry just below the file ends > > with a hole? If so, this seems fine: > > Yes. That's what the old code does. Note that there isn't anything > in xfsprogs or xfstests that ever looks at BMV_OF_LAST to start with. FWIW xfs_scrub tool has a phase that reads all the file data blocks (having sorted them in disk order) to look for read errors, and uses nftw+bmap to map bad blocks back to (file path, offset). So long as there are never any real extents returned after the BMV_OF_LAST record, this semantic is fine... (Will try to review this series and the one before it today.) --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
