On 8/23/17 10:51 AM, Eric Sandeen wrote:

On 8/23/17 10:11 AM, Nikolay Borisov wrote:

quoted

So far fiemap used some rather convoluted logic to terminate the iteration and
calculate the number of extents to pass to fm_extent_count. Simplify this by:

* Get the whole number of extents that this file has and keep iterating until
we've printed all extents

* Always use a hard-coded batch of 32 extents so we don't have to worry about
any extra calculations

As discussed on IRC, these types of changes:

quoted

-	if ((*cur_extent + 1) == max_extents)
+	if (*cur_extent == max_extents)
 		return;

are a functional change not described in the changelog above; they should be
in their own patch with their own changelog, explaining why the test was off by one,
and what this fixes.  This stuff is complex enough that it's not obvious to the
casual reader now, and certainly won't be a few years later.  ;)

Ok, so this is fixing the "-n" argument, to actually print $ARG extents
instead of $ARG - 1 extents.

instead of today:

# xfs_io -c "fiemap -n 4" holefile
holefile:
	0: [0..7]: hole
	1: [8..15]: 172560120..172560127
	2: [16..23]: hole

now it does more expected:

# io/xfs_io -c "fiemap -n 4" holefile
holefile:
	0: [0..7]: hole
	1: [8..15]: 172560120..172560127
	2: [16..23]: hole
	3: [24..31]: 172560136..172560143

so it probably just needs a doc fix along w/ this behavior fix.

(note, bmap behaves the same way, except properly):

# xfs_io -c "bmap -n 4" holefile
holefile:
	0: [0..7]: hole
	1: [8..15]: 172560120..172560127
	2: [16..23]: hole
	3: [24..31]: 172560136..172560143

Thanks,
-Eric

 

Thanks,
-Eric