Re: [PATCH v7] generic: initial fiemap range query test

From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Nikolay Borisov <nborisov@suse.com>,
	eguan@redhat.com, linux-xfs@vger.kernel.org,
	fstests@vger.kernel.org
Subject: Re: [PATCH v7] generic: initial fiemap range query test
Date: Wed, 6 Dec 2017 16:22:21 -0600	[thread overview]
Message-ID: <37bbe246-19bc-f3dc-c72f-600a86fcbdf1@sandeen.net> (raw)
In-Reply-To: <20171206221603.GH5858@dastard>

On 12/6/17 4:16 PM, 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....
> 
>> If you want to have some user-friendlier behavior where xfs_io layers
>> behaviors on top of what the kernel provides, then add a "-t" argument for trim,
>> but hiding ioctl inconsistencies by filtering them through xfs_io sounds
>> like the wrong approach to me.
> 
> Just filter the last output in the test, then, so it looks like
> 
> 2: [128..XXX] data

Would need to do the same for the first extent AIUI.

> There is absolutely no excuse for creating multiple tests to support
> a small difference in trailing extent range output from different
> filesystem.

Excuse #1 is to ensure that for filesystems which return extent data past
the requested range, it's actually correct...

If we trim/filter it away and it returns junk for any reason, we'd never know
via this test.  So I think filtering the first/last lengths is a reasonable
way to force it into a common test, but it reduces the value of the test to
some degree.

-Eric