public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael L. Semon" <mlsemon35@gmail.com>
To: Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 06/15] mkfs: validate logarithmic parameters sanely
Date: Mon, 02 Dec 2013 20:34:39 -0500	[thread overview]
Message-ID: <529D352F.8020306@gmail.com> (raw)
In-Reply-To: <20131202170601.GB14935@infradead.org>

On 12/02/2013 12:06 PM, Christoph Hellwig wrote:
> On Fri, Nov 29, 2013 at 12:43:41PM +1100, Dave Chinner wrote:
>> From: Dave Chinner <dchinner@redhat.com>
>>
>> Testing logarithmic paramters like "-n log=<num>" shows that we do a
>> terrible job of validating such input. e.g.:
>>
>> # mkfs.xfs -f -n log=456858480 /dev/vda
>> .....
>> naming   =version 2              bsize=65536  ascii-ci=0 ftype=0
>> ....
>>
>> Yeah, I just asked for a block size of 2^456858480, and it didn't
>> get rejected. Great, isn't it?
>>
>> So, factor out the parsing of logarithmic parameters, and pass in
>> the maximum valid value that they can take. These maximum values
>> might not be completely accurate (e.g. block/sector sizes will
>> affect the eventual valid maximum) but we can get rid of all the
>> overflows and stupidities before we get to fine-grained validity
>> checking later in mkfs once things like block and sector sizes have
>> been finalised.
> 
> Btw, is there any good reason not to deprecate the logarithmic
> parameters?  I can't see why anyone would want to use them, but I see
> lots of potential for confusion (happened to myself in the past).
> 
> The patch itself looks good:

I use log= almost exclusively.  The habit comes from using ntpd for 
many years.  An ntp.conf line like this...

server ntp.example.org minpoll 4 maxpoll 10

...means "poll server 'ntp.example.org' no fewer than once every 16s,
no greater than once every 1024s."  For XFS, I remember the numbers 
9, 10, and 11, dropping the 12 because it's the default.  At least 
for block sizes, v5 XFS has me dropping the 9 as well.  There are 
many places in computers to remember 1024 and 2048, and they're just 
more readily in mind as 10 and 11.  Personal preference.

Feel free to deprecate it, though.  The change back to non-logarithmic 
notation isn't going to be a problem.  I was just putting in my two 
cents on the matter.

Thanks!

Michael

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2013-12-03  1:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-29  1:43 [RFC, PATCH 00/15] mkfs: sanitise input parameters Dave Chinner
2013-11-29  1:43 ` [PATCH 01/15] xfsprogs: use common code for multi-disk detection Dave Chinner
2013-12-02 10:40   ` Christoph Hellwig
2013-12-02 22:49     ` Dave Chinner
2013-11-29  1:43 ` [PATCH 02/15] mkfs: sanitise ftype parameter values Dave Chinner
2013-12-02 10:40   ` Christoph Hellwig
2013-11-29  1:43 ` [PATCH 03/15] mkfs: Sanitise the superblock feature macros Dave Chinner
2013-12-02 10:43   ` Christoph Hellwig
2013-12-02 22:50     ` Dave Chinner
2013-11-29  1:43 ` [PATCH 04/15] mkfs: validate all input values Dave Chinner
2013-12-02 17:04   ` Christoph Hellwig
2013-12-02 23:12     ` Dave Chinner
2013-12-03  9:42       ` Christoph Hellwig
2013-12-11  4:27         ` Jeff Liu
2013-12-11 23:57           ` Dave Chinner
2013-11-29  1:43 ` [PATCH 05/15] mkfs: factor boolean option parsing Dave Chinner
2013-12-02 10:46   ` Christoph Hellwig
2013-12-02 23:13     ` Dave Chinner
2013-11-29  1:43 ` [PATCH 06/15] mkfs: validate logarithmic parameters sanely Dave Chinner
2013-12-02 17:06   ` Christoph Hellwig
2013-12-02 23:14     ` Dave Chinner
2013-12-03  1:34     ` Michael L. Semon [this message]
2013-11-29  1:43 ` [PATCH 07/15] mkfs: structify input parameter passing Dave Chinner
2013-12-02 17:11   ` Christoph Hellwig
2013-12-02 23:16     ` Dave Chinner
2013-11-29  1:43 ` [PATCH 08/15] mkfs: getbool is redundant Dave Chinner
2013-12-02 17:12   ` Christoph Hellwig
2013-11-29  1:43 ` [PATCH 09/15] mkfs: use getnum_checked for all ranged parameters Dave Chinner
2013-12-02 17:14   ` Christoph Hellwig
2013-11-29  1:43 ` [PATCH 10/15] mkfs: add respecification detection to generic parsing Dave Chinner
2013-12-02 17:15   ` Christoph Hellwig
2013-11-29  1:43 ` [PATCH 11/15] mkfs: table based parsing for converted parameters Dave Chinner
2013-12-02 17:17   ` Christoph Hellwig
2013-11-29  1:43 ` [PATCH 12/15] mkfs: merge getnum Dave Chinner
2013-12-02 17:22   ` Christoph Hellwig
2013-12-02 23:20     ` Dave Chinner
2013-11-29  1:43 ` [PATCH 13/15] mkfs: encode conflicts into parsing table Dave Chinner
2013-12-02 17:23   ` Christoph Hellwig
2013-11-29  1:43 ` [PATCH 14/15] mkfs: add string options to generic parsing Dave Chinner
2013-11-29  1:43 ` [PATCH 15/15] mkfs: don't treat files as though they are block devices Dave Chinner
2013-12-02 17:24   ` Christoph Hellwig
2013-12-02 23:21     ` Dave Chinner

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=529D352F.8020306@gmail.com \
    --to=mlsemon35@gmail.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox