On 12/6/17 4:46 PM, Darrick J. Wong wrote: > On Thu, Dec 07, 2017 at 09:16:03AM +1100, Dave Chinner wrote: >> On Wed, Dec 06, 2017 at 04:01:58PM -0600, Eric Sandeen wrote: >>> On 12/6/17 3:57 PM, Dave Chinner wrote: >>> >>>> There's a *simple answer* to this problem: fix the new command's >>>> output. >>>> >>>> That is: the user asked for a specific range, so the command itself >>>> should trim the map returned by the kernel to only display the exact >>>> range the user asked for. Then it doesn't matter if the underlying >>>> filesystem trims the extents or not, because the we're going to do >>>> that anyway in userspace. >>> >>> I have a different opinion: >>> >>> xfs_io is a debugging tool; the fiemap command sends an ioctl to the kernel. >>> >>> Ranged fiemap queries are a real thing; you put numbers into the kernel, >>> and you get numbers out of the kernel. >>> >>> IMNSO, xfs_io should present to the user /what the kernel returned/, >>> and not re-interpret it to fit some other notion of correctness if we >>> don't like what the kernel told us. >> >> I hardly think "trimming to the range the user asked for" is >> "re-interpreting what the kernel told us". It's limiting output >> range to exactly what the user asked for - the output is still >> correct regardless of how it's filtered to match what the user asked >> for.... > > ...except that xfs_io is a tool we use to debug the garbage that FIEMAP > sprays back at userspace, so it absolutely should not be hiding things > like this from the test suite: That's the point I was trying, I guess badly, to make. If I send a patch for xfs which essentially does this in fiemap: if (ranged_query && last_block_in_range_allocated) last_extent.length += 42; have I introduced a bug or not? -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
