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@xxxxxxxxxx> >> >> 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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
