All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Gao Xiang <hsiangkao@redhat.com>
Cc: linux-xfs@vger.kernel.org,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Eric Sandeen <sandeen@redhat.com>,
	Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH v5 3/3] mkfs: make use of xfs_validate_stripe_factors()
Date: Mon, 12 Oct 2020 10:20:20 -0400	[thread overview]
Message-ID: <20201012142020.GG917726@bfoster> (raw)
In-Reply-To: <20201012140715.GB614@xiangao.remote.csb>

On Mon, Oct 12, 2020 at 10:07:15PM +0800, Gao Xiang wrote:
> Hi Brian,
> 
> On Mon, Oct 12, 2020 at 09:06:51AM -0400, Brian Foster wrote:
> > On Fri, Oct 09, 2020 at 01:24:21PM +0800, Gao Xiang wrote:
> > > Check stripe numbers in calc_stripe_factors() by using
> > > xfs_validate_stripe_factors().
> > > 
> > > Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
> > > ---
> > >  libxfs/libxfs_api_defs.h |  1 +
> > >  mkfs/xfs_mkfs.c          | 23 +++++++----------------
> > >  2 files changed, 8 insertions(+), 16 deletions(-)
> > > 
> > ...
> > > @@ -2344,11 +2334,12 @@ _("data stripe width (%d) must be a multiple of the data stripe unit (%d)\n"),
> > >  
> > >  	/* if no stripe config set, use the device default */
> > >  	if (!dsunit) {
> > > -		/* Ignore nonsense from device.  XXX add more validation */
> > > -		if (ft->dsunit && ft->dswidth == 0) {
> > > +		/* Ignore nonsense from device report. */
> > > +		if (!libxfs_validate_stripe_factors(NULL, BBTOB(ft->dsunit),
> > > +						    BBTOB(ft->dswidth), 0)) {
> > 
> > The logic seems fine and from the previous comment it sounds like we're
> > lacking validation in this particular scenario, but do we want to print
> > more error noise from the validation helper in scenarios where failure
> > is not a fatal error?
> 
> Yeah, If I understand correctly, I think that is an open question here,
> so I think you suggested that we could silence for this case by passing
> a "bool silent" argument? or some better idea for this?
> 

Sure, that seems reasonable to me. Maybe others have thoughts. My
concern was primarily based on usability in terms of not potentially
confusing users with spurious error messages.

Brian

> Thanks,
> Gao Xiang
> 
> > 
> > Brian
> > 
> > >  			fprintf(stderr,
> > > -_("%s: Volume reports stripe unit of %d bytes and stripe width of 0, ignoring.\n"),
> > > -				progname, BBTOB(ft->dsunit));
> > > +_("%s: Volume reports invalid stripe unit (%d) and stripe width (%d), ignoring.\n"),
> > > +				progname, BBTOB(ft->dsunit), BBTOB(ft->dswidth));
> > >  			ft->dsunit = 0;
> > >  			ft->dswidth = 0;
> > >  		} else {
> > > -- 
> > > 2.18.1
> > > 
> > 
> 


      reply	other threads:[~2020-10-12 14:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09  5:24 [PATCH v5 0/3] xfsprogs: consolidate stripe validation Gao Xiang
2020-10-09  5:24 ` [PATCH v5 1/3] libxfs: allow i18n to xfs printk Gao Xiang
2020-10-09  5:24 ` [PATCH v5 2/3] xfs: introduce xfs_validate_stripe_factors() Gao Xiang
2020-10-09  5:24 ` [PATCH v5 3/3] mkfs: make use of xfs_validate_stripe_factors() Gao Xiang
2020-10-12 13:06   ` Brian Foster
2020-10-12 14:07     ` Gao Xiang
2020-10-12 14:20       ` Brian Foster [this message]

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=20201012142020.GG917726@bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hsiangkao@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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.