[Lustre-devel] loadgen improvements
Andreas Dilger
adilger at sun.com
Wed Dec 9 23:33:25 PST 2009
On 2009-12-08, at 23:57, Alexey Lyashkov wrote:
> On Tue, 2009-12-08 at 23:35 -0700, Andreas Dilger wrote:
>> On 2009-12-08, at 22:07, Alexey Lyashkov wrote:
>>> This can be something similar as
>>
>>>
>>> pattern $name $pool_name $operation [$stripe_size
>>> [$stripe_count]]
>>
>> Please do not use positional parameters. That makes it nearly
>> impossible to change the input format in the future, or to skip some
>> fields and leave them as defaults. This needs to use getopt() and
>> named parameters:
>>
>> --pool=pool_name, --stripe_size=N, --stripe_count=N
>
> This possible, but unlikely. because need will be save current pool
> name, instead have parsed as single command.
>
> And I don't have plan to rewrite loadgen to use getopt, instead of
> current Parser() function which is used in lctl, lfs, and other.
Note that the existing parser function passes argc, argv to the helper
function, which is free to use getopt() or getopt_long() internally as
desired. See, for example, lustre/utils/lfs.c::lfs_setstripe(), which
handles the parsing of "lfs setstripe --count N --pool {pool} ...".
> How about this style
>>
> pool $name { targets:"OST1, OST2" }
> pattern $pat { stripe_count:X stripe_size:Y block_size:Z };
> clients $pattern { count:XX pattern: pat shared }
I have no objection to splitting up the functionality into multiple
sub-commands. Allowing declarations of pools and patterns that are re-
used for each client definition makes a lot of sense.
What I dislike is the introduction of a completely new input format
and parsing engine for no apparent benefit. Why not change the above
to:
loadgen> pool --targets="OST1,OST2,..." NAME
loadgen> pattern --stripe_count=X --stripe_size=Y --block_size=Z PATTERN
loadgen> clients --count=XX --pattern=PATTERN ...
and use well-known input conventions?
It also makes sense to look at how LNET Self Test handles the setup of
testing loads, and try and make the loadgen usage similar to that, as
much as possible?
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
More information about the lustre-devel
mailing list