On 2/15/16 2:40 PM, Dave Chinner wrote:
> On Mon, Feb 15, 2016 at 02:28:36PM -0500, Jim Wilcoxson wrote:
>> Thanks Eric.
>>
>> I ran xfs_bmap -v and it returned extents 0-19999, alternating data
>> with holes. The holes and data were various sizes, I suppose for xfs
>> alignment reasons, but everything was there.
>>
>> Running fiemap again after xfs_bmap still returned 1364 extents.
>
> Yes, fiemap in XFS uses a buffer size of:
>
> bm.bmv_count = min_t(__s32, bm.bmv_count,
> (PAGE_SIZE * 16 / sizeof(struct getbmapx)));
>
> i.e. limits a single fiemap fetch to a maximum of 64k of extent
> data.
>
> I think you have an incorrect assumption about fiemap behaviour.
> fiemap is not designed to return or even count all the extents in a
> file in a single call;
I think it is; as was quoted earlier,
"If fm_extent_count is zero, then the
fm_extents[] array is ignored (no extents will be returned), and the
fm_mapped_extents count will hold the number of extents needed in
fm_extents[] to hold the file's current mapping."
and that's in there:
/* only count the extents */
if (fieinfo->fi_extents_max == 0) {
fieinfo->fi_extents_mapped++;
return (flags & FIEMAP_EXTENT_LAST) ? 1 : 0;
}
> on XFS it returns how many extents it can
> return in a single call. When you then map the file, if the
> FIEMAP_EXTENT_LAST is not set on the last extent returned, then the
> application needs to make another FIEMAP call from the end offset of
> last extent mapping returned in the last call, and it will then
> return the next N extents in the file.
>
> IOWs, you have to keep calling FIEMAP to map the entire file, not
> assume a single call will return an arbitrary amount of data to you
> in a single call.
He's not trying to get all data in one call, just a count.
-Eric
> But, as Eric said - fiemap is a diagnosis tool, not an interface you
> can rely on for anything involving data movement.
>
> Cheers,
>
> Dave.
>
|