[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200408004801.GH24067@dread.disaster.area>
Date: Wed, 8 Apr 2020 10:48:01 +1000
From: Dave Chinner <david@...morbit.com>
To: Ira Weiny <ira.weiny@...el.com>
Cc: linux-kernel@...r.kernel.org,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Dan Williams <dan.j.williams@...el.com>,
Christoph Hellwig <hch@....de>,
"Theodore Y. Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>,
Jeff Moyer <jmoyer@...hat.com>, linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH V6 4/8] fs/xfs: Make DAX mount option a tri-state
On Tue, Apr 07, 2020 at 05:09:04PM -0700, Ira Weiny wrote:
> On Wed, Apr 08, 2020 at 09:59:09AM +1000, Dave Chinner wrote:
> > On Tue, Apr 07, 2020 at 11:29:54AM -0700, ira.weiny@...el.com wrote:
> > > From: Ira Weiny <ira.weiny@...el.com>
> > >
> > > As agreed upon[1]. We make the dax mount option a tri-state. '-o dax'
> > > continues to operate the same. We add 'always', 'never', and 'iflag'
> > > (default).
> > >
> > > [1] https://lore.kernel.org/lkml/20200405061945.GA94792@iweiny-DESK2.sc.intel.com/
> > >
> > > Signed-off-by: Ira Weiny <ira.weiny@...el.com>
> > >
> > > ---
> > > Changes from v5:
> > > New Patch
> > > ---
> > > fs/xfs/xfs_iops.c | 2 +-
> > > fs/xfs/xfs_mount.h | 26 +++++++++++++++++++++++++-
> > > fs/xfs/xfs_super.c | 34 +++++++++++++++++++++++++++++-----
> > > 3 files changed, 55 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> > > index 81f2f93caec0..1ec4a36917bd 100644
> > > --- a/fs/xfs/xfs_iops.c
> > > +++ b/fs/xfs/xfs_iops.c
> > > @@ -1248,7 +1248,7 @@ xfs_inode_supports_dax(
> > > return false;
> > >
> > > /* DAX mount option or DAX iflag must be set. */
> > > - if (!(mp->m_flags & XFS_MOUNT_DAX) &&
> > > + if (xfs_mount_dax_mode(mp) != XFS_DAX_ALWAYS &&
> > > !(ip->i_d.di_flags2 & XFS_DIFLAG2_DAX))
> > > return false;
> > >
> > > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> > > index 88ab09ed29e7..ce027ee06692 100644
> > > --- a/fs/xfs/xfs_mount.h
> > > +++ b/fs/xfs/xfs_mount.h
> > > @@ -233,7 +233,31 @@ typedef struct xfs_mount {
> > > allocator */
> > > #define XFS_MOUNT_NOATTR2 (1ULL << 25) /* disable use of attr2 format */
> > >
> > > -#define XFS_MOUNT_DAX (1ULL << 62) /* TEST ONLY! */
> > > +/* DAX flag is a 2 bit field representing a tri-state for dax
> > > + * iflag, always, never
> > > + * We reserve/document the 2 bits using dax field/field2
> > > + */
> > > +#define XFS_DAX_FIELD_MASK 0x3ULL
> > > +#define XFS_DAX_FIELD_SHIFT 62
> > > +#define XFS_MOUNT_DAX_FIELD (1ULL << 62)
> > > +#define XFS_MOUNT_DAX_FIELD2 (1ULL << 63)
> > > +
> > > +enum {
> > > + XFS_DAX_IFLAG = 0,
> > > + XFS_DAX_ALWAYS = 1,
> > > + XFS_DAX_NEVER = 2,
> > > +};
> > > +
> > > +static inline void xfs_mount_set_dax(struct xfs_mount *mp, u32 val)
> > > +{
> > > + mp->m_flags &= ~(XFS_DAX_FIELD_MASK << XFS_DAX_FIELD_SHIFT);
> > > + mp->m_flags |= ((val & XFS_DAX_FIELD_MASK) << XFS_DAX_FIELD_SHIFT);
> > > +}
> > > +
> > > +static inline u32 xfs_mount_dax_mode(struct xfs_mount *mp)
> > > +{
> > > + return (mp->m_flags >> XFS_DAX_FIELD_SHIFT) & XFS_DAX_FIELD_MASK;
> > > +}
> >
> > This is overly complex. Just use 2 flags:
>
> LOL... I was afraid someone would say that. At first I used 2 flags with
> fsparam_string, but then I realized Darrick suggested fsparam_enum:
Well, I'm not concerned about the fsparam enum, it's just that
encoding an integer into a flags bit field is just ... messy.
Especially when encoding that state can be done with just 2 flags.
If you want to keep the xfs_mount_dax_mode() wrapper, then:
static inline uint32_t xfs_mount_dax_mode(struct xfs_mount *mp)
{
if (mp->m_flags & XFS_MOUNT_DAX_NEVER)
return XFS_DAX_NEVER;
if (mp->m_flags & XFS_MOUNT_DAX_ALWAYS)
return XFS_DAX_ALWAYS;
return XFS_DAX_IFLAG;
}
but once it's encoded in flags like this, the wrapper really isn't
necessary...
Also, while I think of it, can we change "iflag" to "inode". i.e.
the DAX state is held on the inode. Saying it comes from an "inode
flag" encodes the implementation into the user interface. i.e. it
could well be held in an xattr on the inode on another filesystem,
so we shouldn't mention "flag" in the user API....
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists