On 8/23/17 10:51 AM, Eric Sandeen wrote: > On 8/23/17 10:11 AM, Nikolay Borisov wrote: >> 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: > >> - 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 > -- 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
