On 2/18/25 03:59, Dave Chinner wrote:
On Mon, Feb 17, 2025 at 10:18:48AM +0530, Nirjhar Roy (IBM) wrote:
On 2/14/25 03:19, Dave Chinner wrote:
On Thu, Feb 13, 2025 at 03:30:50PM +0530, Nirjhar Roy (IBM) wrote:
On 2/13/25 03:17, Dave Chinner wrote:
On Wed, Feb 12, 2025 at 12:39:58PM +0000, Nirjhar Roy (IBM) wrote:
Ok, so CONFIG_XFS_SUPPORT_V4=n is the correct behaviour (known mount
option, invalid configuration being asked for), and it is the
CONFIG_XFS_SUPPORT_V4=y behaviour that is broken.
Okay, so do you find this testcase (patch 3/3 xfs: Add a testcase to check
remount with noattr2 on a v5 xfs) useful,
Not at this point in time, because xfs/189 is supposed to exercise
attr2/noattr2 mount/remount behaviour and take into account all the
weirdness of the historic mount behaviour.
Obviously, it is not detecting that this noattr2 remount behaviour
was broken, so that test needs fixing/additions. Indeed, it's
probably important to understand why xfs/189 isn't detecting this
failure before going any further, right?
Yes. Let me look into what xfs/189 does and why it isn't detecting the
noattr2 remount broken behavior. Thank you for the pointer.
About "Patch 1/3: xfs/539: Skip noattr2 remount option on v5 file
systems" --> I wrote the patch because xfs/539 has started failing in
one of fstests CI runs because RHEL 10 has started disabling xfs v4
support i.e, CONFIG_XFS_SUPPORT_V4=n. Do you think modifying patch
1/3(xfs/539) in such a way that the test ignores the remount failures
with noattr2 and continues the test is an appropriate idea (since the
test xfs/539 only intends to check the dmesg warnings)?
--NR
IMO, it is better to fix existing tests that exercise the behaviour
in question than it is to add a new test that covers just what the
old test missed.
-Dave.
--
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore
