KB are pretty small units these days. Using 'vos setfields foo -
maxquota' as a test case, I'd like to add the following to argument
handling when afs utilities use number that are multiples of 1024 on
the command line:
1 - 1024 bytes
1K - 1024 bytes
1M - 1024 * 1024 bytes
1G - 1024 * 1024 * 1024 bytes
and so on through tera and peta. Anybody think we'll be running
greater-than-petaKbybe volumes before afs3? I didn't think so. :-)
I don't think doing a simultaneous powers-of-10 implementation is a
good idea. IMHO
1m = 1000K (1,024,000)
1g = 1000m (1,024,000,000)
is inherently confusing to end users and I don't think anybody wants
to explain to them why quotas are sooo much easier with 1K units.
Historically I've found most users happier when told "because that's
how computers work" as long as it results in them getting more than
they expected (cf the recent Seagate lawsuit). And I don't think
there's much utility for us admins gained by [kmgtp] as powers of
1000 'cause it's pretty easy to remember three zeros is a power of
1000. Remembering the base 10 expression of 1M, 1G, and their
multiples is a lot harder.
I'm open to argument on fractions, ie, should .5G or 1.5G be allowed,
and if so what they should mean. My off-the-cuff assessment is that
no, don't allow. But if it was allowed, I'd say it should be a
multiplier on the K/M/G value, eg, .5G is 1024 * 1204 * 1024 *.5,
rounded to the nearest whole 1024 bytes.
To be a bit more specific, then, I propose that numbers which are
inherently expressed as kilobytes be allowed in the form of this
possibly sloppy regexp:
\<d*(.d*)?([KMGTPkmgtp]([Bb])?)?\>
In english:
o must begin and end on a word boundary (the \< and \>)
o one or more digits are required [0-9]
o may be followed by a fractional part
o may be followed by K, M, G, T or P, meaning appropriate powers
of 1024
o KMTGP may be in upper or lower case
o if KMTGP present, may be followed by an upper or lower case B
o In the absence of KMTGP, K is assumed
For an initial implementation, I'd make this modification to 'vos
setf' and maybe 'fs setq' as a test. Assuming it works well, we'd
then start adding it to any other appropriate parts of the AFS
utilities. If there are any.
Caveat: I've not looked at the command line processing code since
starting this idea. I know there's a lot of 'standard AFS arg
processing' in there, but haven't looked at the issue of modifying or
extending it.
Steve
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
