public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Jan Tulak <jtulak@redhat.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 6/6 v2] mkfs: extend opt_params with a value field
Date: Wed, 16 Aug 2017 14:38:12 -0700	[thread overview]
Message-ID: <20170816213812.GC4796@magnolia> (raw)
In-Reply-To: <4a7d1fe9-8094-78e8-aca9-f7f0156f0aa7@sandeen.net>

On Wed, Aug 16, 2017 at 04:13:52PM -0500, Eric Sandeen wrote:
> On 8/15/17 10:08 AM, Jan Tulak wrote:
> > This patch adds infrastructure that will be used in subsequent patches.
> > 
> > The Value field is the actual value used in computations for creating
> > the filesystem.  This is initialized with sensible default values. If
> > initialized to 0, the value is considered disabled. User input will
> > override default values.  If the field is a string and not a number, the
> > value is set to a positive non-zero number when user input has been
> > supplied.
> > 
> > Add functions that can be used to get/set values to opts table.
> 
> Ok, I need to back up here a bit and look at this conceptually.
> 
> (Again, though, if this is infra for some other patchset, I'd just send
> it with /that/ patchset, not this one ...)
> 
> But anyway, things like this confuse and worry me:
> 
> > +	case OPT_S:
> > +		switch (subopt) {
> > +		case S_LOG:
> > +		case S_SECTLOG:
> > +			set_conf_val(OPT_S, S_LOG, val);
> > +			set_conf_val(OPT_D, D_SECTLOG, val);
> > +			set_conf_val(OPT_L, L_SECTLOG, val);
> > +			set_conf_val(OPT_D, D_SECTSIZE, 1 << val);
> > +			set_conf_val(OPT_S, S_SIZE, 1 << val);
> > +			set_conf_val(OPT_S, S_SECTSIZE, 1 << val);
> > +			set_conf_val(OPT_L, L_SECTLOG, val);
> > +			set_conf_val(OPT_L, L_SECTSIZE, 1 << val);
> > +			set_conf_val(OPT_L, L_SECTSIZE, val);> +			break;
> > +		case S_SIZE:
> > +		case S_SECTSIZE:
> > +			set_conf_val(OPT_S, S_SIZE, val);
> > +			set_conf_val(OPT_D, D_SECTSIZE, val);
> > +			set_conf_val(OPT_D, D_SECTLOG, libxfs_highbit32(val));
> > +			set_conf_val(OPT_S, S_LOG, libxfs_highbit32(val));
> > +			set_conf_val(OPT_S, S_SECTLOG, libxfs_highbit32(val));
> > +			set_conf_val(OPT_L, L_SECTSIZE, val);
> > +			set_conf_val(OPT_L, L_SECTLOG, libxfs_highbit32(val));
> > +			break;
> > +		}
> > +		break;
> > +	}
> 
> Partly because this seems to be going opposite of the simplicity
> we were aiming for - before all this work, if we set teh data sector size,
> via any of these options, it got stored in a variable - "sectorsize".
> 
> Now, if we issue "-s size=4k" the code will calculate and set that same
> value (or its log) into 7 to (or 9?) different internal variables?
> Why is that needed?  There is/are only one (or two) sector size(s) in the
> filesystem, so should there not be one point of truth here?
> 
> But also because the above is wrong; it is possible for the filesystem data
> portion and log portion to have different sector sizes, if the log is external. [1]
> The above would seem to break that, always setting data & log sizes together.
> 
> On top of that, it's getting so complicated that it seems to be difficult to get
> right; i.e. this:
> 
> > +			set_conf_val(OPT_L, L_SECTSIZE, 1 << val);
> > +			set_conf_val(OPT_L, L_SECTSIZE, val);
> 
> surely isn't correct.  I found that when noticing that 1 block sets 9 vals, while
> the other only 7, and wondered why.  So that accounts for one.  After another minute
> of scrutiny I see that OPT_S, S_SECTSIZE isn't set in the 2nd chunk, so that's a bug
> as well.
> 
> This makes me fear fragility in this approach.
> 
> One goal of all this work, I thought, was to clearly describe interdependencies between
> options, but the above seems to add nasty, hidden, implicit, and wrong dependencies
> between log & data sector sizes (for example).

FWIW I thought all this really did was replace the dozens of local
variables holding geometry info with a huge nested struct, which is a
reasonable start on adding support for a config file (where is that,
anyway?) but didn't make any functional changes.

Ofc I didn't realize that xfs/191-input-validation isn't a totally
thorough exerciser of all the mkfs options.

> If we have several commandline options that all set the same fundamental property,
> (i.e. data sector size), then it seems that should somehow be stored in one single
> point of truth within mkfs as it was before.
> 
> -Eric
> 
> [1] # mkfs.xfs -dfile,name=fsfile,size=1g,sectsize=4k -lfile,name=logfile,size=512m,sectsize=512

I see -d sectsize is in the --help screen but not the manpage.  Can we
fix that?

--D

> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-08-16 21:38 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11 12:30 [PATCH 0/6 v2] mkfs: save user input into opts table Jan Tulak
2017-08-11 12:30 ` [PATCH 1/6] mkfs: Save raw user input field to the opts struct Jan Tulak
2017-08-14 22:56   ` Darrick J. Wong
2017-08-15  9:47     ` Jan Tulak
2017-08-11 12:30 ` [PATCH 2/6] mkfs: rename defaultval to flagval in opts Jan Tulak
2017-08-14 22:56   ` Darrick J. Wong
2017-08-11 12:30 ` [PATCH 3/6] mkfs: remove intermediate getstr followed by getnum Jan Tulak
2017-08-14 22:58   ` Darrick J. Wong
2017-08-11 12:30 ` [PATCH 4/6] mkfs: merge tables for opts parsing into one table Jan Tulak
2017-08-14 23:06   ` Darrick J. Wong
2017-08-15 10:05     ` Jan Tulak
2017-08-11 12:30 ` [PATCH 5/6] mkfs: move getnum within the file Jan Tulak
2017-08-14 23:07   ` Darrick J. Wong
2017-08-15 10:14     ` Jan Tulak
2017-08-15 21:09       ` Eric Sandeen
2017-08-16  9:25         ` Jan Tulak
2017-08-11 12:30 ` [PATCH 6/6] mkfs: extend opt_params with a value field Jan Tulak
2017-08-14 23:15   ` Darrick J. Wong
2017-08-15 10:42     ` Jan Tulak
2017-08-15 15:08 ` [PATCH 1/6 v2] mkfs: Save raw user input field to the opts struct Jan Tulak
2017-08-15 15:08   ` [PATCH 3/6 v2] mkfs: remove intermediate getstr followed by getnum Jan Tulak
2017-08-15 23:20     ` Eric Sandeen
2017-08-17 11:36     ` Dave Chinner
2017-08-15 15:08   ` [PATCH 4/6 v2] mkfs: merge tables for opts parsing into one table Jan Tulak
2017-08-15 15:08   ` [PATCH 5/6 v2] mkfs: move getnum within the file Jan Tulak
2017-08-15 15:08   ` [PATCH 6/6 v2] mkfs: extend opt_params with a value field Jan Tulak
2017-08-16 21:13     ` Eric Sandeen
2017-08-16 21:38       ` Darrick J. Wong [this message]
2017-08-17 10:08         ` Jan Tulak
2017-08-17 11:03           ` Dave Chinner
2017-08-17 14:56             ` Jan Tulak
2017-08-17 22:59               ` Dave Chinner
2017-08-17 15:26           ` Eric Sandeen
2017-08-15 23:07   ` [PATCH 1/6 v2] mkfs: Save raw user input field to the opts struct Eric Sandeen
2017-08-16  9:11     ` Jan Tulak
2017-08-16 14:42       ` Eric Sandeen
2017-08-16 15:38         ` Jan Tulak

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=20170816213812.GC4796@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=jtulak@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox