<div>My message to lustre-devel will be held by the moderator for ever it seems (13 days ago I sent the first one).</div><div><br></div>The "standard" conventions have led to an extremely limited set of benchmarks being executed, of questionable value.  <div>
<br></div><div>We need expressiveness that is sufficient to also describe realistic scenarios, like out of order or biased delivery of requests (such was shown to be critical at ORNL), mixing in smaller and bigger I/O.  I believe what Umka and Alexey are showing is the beginning of the language we are developing for this.<div>
<br></div><div>peter<br><br><div class="gmail_quote">On Thu, Dec 10, 2009 at 12:33 AM, Andreas Dilger <span dir="ltr"><<a href="mailto:adilger@sun.com">adilger@sun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 2009-12-08, at 23:57, Alexey Lyashkov wrote:<br>
> On Tue, 2009-12-08 at 23:35 -0700, Andreas Dilger wrote:<br>
>> On 2009-12-08, at 22:07, Alexey Lyashkov wrote:<br>
>>> This can be something similar as<br>
>><br>
>>><br>
>>>    pattern $name $pool_name $operation [$stripe_size<br>
>>> [$stripe_count]]<br>
>><br>
</div><div class="im">>> Please do not use positional parameters.  That makes it nearly<br>
>> impossible to change the input format in the future, or to skip some<br>
>> fields and leave them as defaults.  This needs to use getopt() and<br>
>> named parameters:<br>
>><br>
>>  --pool=pool_name, --stripe_size=N,  --stripe_count=N<br>
><br>
> This possible, but unlikely. because need will be save current pool<br>
> name, instead have parsed as single command.<br>
><br>
> And I don't have plan to rewrite loadgen to use getopt, instead of<br>
> current Parser() function which is used in lctl, lfs, and other.<br>
<br>
</div>Note that the existing parser function passes argc, argv to the helper<br>
function, which is free to use getopt() or getopt_long() internally as<br>
desired.  See, for example, lustre/utils/lfs.c::lfs_setstripe(), which<br>
handles the parsing of "lfs setstripe --count N --pool {pool} ...".<br>
<div class="im"><br>
> How about this style<br>
>><br>
> pool $name { targets:"OST1, OST2" }<br>
</div><div class="im">> pattern $pat { stripe_count:X stripe_size:Y block_size:Z };<br>
</div><div class="im">> clients $pattern { count:XX pattern: pat shared }<br>
<br>
<br>
</div>I have no objection to splitting up the functionality into multiple<br>
sub-commands.  Allowing declarations of pools and patterns that are re-<br>
used for each client definition makes a lot of sense.<br>
<br>
What I dislike is the introduction of a completely new input format<br>
and parsing engine for no apparent benefit.  Why not change the above<br>
to:<br>
<br>
loadgen> pool --targets="OST1,OST2,..." NAME<br>
loadgen> pattern --stripe_count=X --stripe_size=Y --block_size=Z PATTERN<br>
loadgen> clients --count=XX --pattern=PATTERN ...<br>
<br>
and use well-known input conventions?<br>
<br>
It also makes sense to look at how LNET Self Test handles the setup of<br>
testing loads, and try and make the loadgen usage similar to that, as<br>
much as possible?<br>
<br>
Cheers, Andreas<br>
<font color="#888888">--<br>
Andreas Dilger<br>
Sr. Staff Engineer, Lustre Group<br>
Sun Microsystems of Canada, Inc.<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Lustre-devel mailing list<br>
<a href="mailto:Lustre-devel@lists.lustre.org">Lustre-devel@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/mailman/listinfo/lustre-devel" target="_blank">http://lists.lustre.org/mailman/listinfo/lustre-devel</a><br>
</div></div></blockquote></div><br></div></div>