[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aAuIn7zbSNRzQ3WH@infradead.org>
Date: Fri, 25 Apr 2025 06:05:35 -0700
From: Christoph Hellwig <hch@...radead.org>
To: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>, linux-xfs@...r.kernel.org,
linux-ext4@...r.kernel.org, fstests@...r.kernel.org,
ritesh.list@...il.com, ojaswin@...ux.ibm.com, djwong@...nel.org,
zlang@...nel.org, david@...morbit.com
Subject: Re: [PATCH v1] xfs: Fail remount with noattr2 on a v5 xfs with
CONFIG_XFS_SUPPORT_V4=y
Hi Nirjhar,
sorry for the delay, I dropped the ball while on vacation.
On Wed, Apr 16, 2025 at 01:05:46PM +0530, Nirjhar Roy (IBM) wrote:
>
> Yes, we need a second pass and I think that is already being done by
> xfs_finish_flags() in xfs_fs_fill_super(). However, in xfs_fs_reconfigure(),
> we still need a check to make a transition from /* attr2 -> noattr2 */ and
> /* noattr2 -> attr2 */ (only if it is permitted to) and update
> mp->m_features accordingly, just like it is being done for inode32 <->
> inode64, right?
Yes.
> Also, in your previous reply[1], you did suggest moving the
> crc+noattr2 check to xfs_fs_validate_params() - Are you suggesting to add
> another optional (NULLable) parameter "new_mp" to xfs_fs_validate_params()
> and then moving the check to xfs_fs_validate_params()?
No, let's skip that.
But we really should share the code for the validation. So while a lot
of the checks in xfs_finish_flags are uselss in remount, it might still
be a good idea to just use that for the option validation so that we
don't miss checks in remount.
Powered by blists - more mailing lists