All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] mkfs: allow setting dax flag on root directory
Date: Tue, 11 Aug 2020 12:54:45 -0700	[thread overview]
Message-ID: <20200811195445.GE6107@magnolia> (raw)
In-Reply-To: <3331be1f-87de-074a-65ac-2491a97b3f80@sandeen.net>

On Tue, Aug 11, 2020 at 02:39:01PM -0500, Eric Sandeen wrote:
> On 8/11/20 9:42 AM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Teach mkfs to set the DAX flag on the root directory so that all new
> > files can be created in dax mode.  This is a complement to removing the
> > mount option.
> 
> So, a new -d option, "-d dax"
> 
> This is ~analogous to cowextsize, rtinherit, projinherit, and extszinherit
> so there is certainly precedence for this.  (where only rtinherit is a boolean
> like this, but they are all inheritable behaviors)
> 
> (I wonder if "daxinherit" would be more consistent, but won't bikeshed
> that (much))

/me is indifferent either way.  But I guess some day we might want to
have a dax= flag to indicate something like "set the data device
geometry to optimize for DAX?

Nah, I think if we were ever going to do that, we'd have something more
like:

	-d usage=dax
	-d usage=ssd
	-d usage=floopy

Meh.  I'll change it to daxinherit, since that /is/ what it does.

> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> >  man/man8/mkfs.xfs.8 |   11 +++++++++++
> >  mkfs/xfs_mkfs.c     |   14 ++++++++++++++
> >  2 files changed, 25 insertions(+)
> > 
> > 
> > diff --git a/man/man8/mkfs.xfs.8 b/man/man8/mkfs.xfs.8
> > index 9d762a43011a..4b4fdd86b2f4 100644
> > --- a/man/man8/mkfs.xfs.8
> > +++ b/man/man8/mkfs.xfs.8
> > @@ -394,6 +394,17 @@ All inodes created by
> >  will have this extent size hint applied.
> >  The value must be provided in units of filesystem blocks.
> >  Directories will pass on this hint to newly created children.
> > +.TP
> > +.BI dax= value
> > +All inodes created by
> > +.B mkfs.xfs
> > +will have the DAX flag set.
> > +This means that directories will pass the flag on to newly created files
> 
> let's call this "children" to match the other similar options?
> 
> (because technically it is passed on not only to regular files, right?)

Directories and regular files, though not to other special files.
Maybe we should fix that.

> > +and files will use the DAX IO paths when possible.
> > +This value is either 1 to enable the use or 0 to disable.
> > +By default,
> > +.B mkfs.xfs
> > +will not enable DAX mode.
> >  .RE
> >  .TP
> >  .B \-f
> > diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> > index 2e6cd280e388..33507f6ea21c 100644
> > --- a/mkfs/xfs_mkfs.c
> > +++ b/mkfs/xfs_mkfs.c
> > @@ -60,6 +60,7 @@ enum {
> >  	D_PROJINHERIT,
> >  	D_EXTSZINHERIT,
> >  	D_COWEXTSIZE,
> > +	D_DAX,
> >  	D_MAX_OPTS,
> >  };
> >  
> > @@ -254,6 +255,7 @@ static struct opt_params dopts = {
> >  		[D_PROJINHERIT] = "projinherit",
> >  		[D_EXTSZINHERIT] = "extszinherit",
> >  		[D_COWEXTSIZE] = "cowextsize",
> > +		[D_DAX] = "dax",
> >  	},
> >  	.subopt_params = {
> >  		{ .index = D_AGCOUNT,
> > @@ -369,6 +371,12 @@ static struct opt_params dopts = {
> >  		  .maxval = UINT_MAX,
> >  		  .defaultval = SUBOPT_NEEDS_VAL,
> >  		},
> > +		{ .index = D_DAX,
> > +		  .conflicts = { { NULL, LAST_CONFLICT } },
> 
> er....  should we conflict with reflink ....  ?
> 
> > +		  .minval = 0,
> > +		  .maxval = 1,
> > +		  .defaultval = 1,
> 
> Hm, interesting that this is a little different from rtinherit:
> 
>                 { .index = D_RTINHERIT,
>                   .conflicts = { { NULL, LAST_CONFLICT } },
>                   .minval = 1,
>                   .maxval = 1,
>                   .defaultval = 1,
>                 },
> 
> I think this means that:
> 
> -d rtinherit
> -d rtinherit=1
> 
> are valid, but
> 
> -d rtinherit=0 is not, but
> 
> -d dax
> -d dax=1
> -d dax=0
> 
> are all valid?

TBH, I find it a little odd that you *can't* say "-d rtinherit=0" from a
completeness perspective, but...

> While the latter makes a bit more sense, I wonder if we should stay
> consistent w/ the rtinherit semantics.  Or do you envision some sort
> of automatic enabling of this based on device typethat we'd need to
> override in the future?

...the goal is to set this automatically once distros start shipping a
libblkid that has blkid_topology_get_dax().  At that point we'll
probably want a way to force it off.

Unless we want the ability to specify -ddax=0 the magic seekrit hook to
discover if (future) mkfs actually supports dax autodetection?  Hmm,
that alone sounds like sufficient justification.  Ok.

--D

> 
> > +		},
> >  	},
> >  };
> >  
> > @@ -1434,6 +1442,12 @@ data_opts_parser(
> >  		cli->fsx.fsx_cowextsize = getnum(value, opts, subopt);
> >  		cli->fsx.fsx_xflags |= FS_XFLAG_COWEXTSIZE;
> >  		break;
> > +	case D_DAX:
> > +		if (getnum(value, opts, subopt))
> > +			cli->fsx.fsx_xflags |= FS_XFLAG_DAX;
> > +		else
> > +			cli->fsx.fsx_xflags &= ~FS_XFLAG_DAX;
> > +		break;
> >  	default:
> >  		return -EINVAL;
> >  	}
> > 

  reply	other threads:[~2020-08-11 19:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11 16:42 [PATCH 0/2] xfsprogs: various small enhancements Darrick J. Wong
2020-08-11 16:42 ` [PATCH 1/2] xfs_db: fix nlink usage in check Darrick J. Wong
2020-08-11 19:25   ` Eric Sandeen
2020-08-11 16:42 ` [PATCH 2/2] mkfs: allow setting dax flag on root directory Darrick J. Wong
2020-08-11 19:39   ` Eric Sandeen
2020-08-11 19:54     ` Darrick J. Wong [this message]
2020-08-11 20:02       ` Eric Sandeen
2020-08-11 20:18         ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200811195445.GE6107@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.