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
next prev parent 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