https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-17155 Lustre <p>Let's try and simplify the output of lfs getstripe so that it's easier to read and understand the components involved. </p> <p>Right now the output can be in text format or yaml, however we should provide another options -H for "human readable" which breaks it down into a nice chart of some kind.</p> LU-17155

Simplify the output of lfs getstripe

New Feature Trivial Open Unresolved Vitaliy Kuznetsov Colin Faber Thu, 28 Sep 2023 14:19:48 +0000 Fri, 29 Sep 2023 01:28:01 +0000 0 4 <p>Before any development is done on this, <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=pbojanic_wc" class="user-hover" rel="pbojanic_wc">pbojanic_wc</a> and <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=cfaber" class="user-hover" rel="cfaber">cfaber</a> can you please provide a text mock-up of what you want to see? Otherwise, this could be a large bike shedding activity that spends a lot of time and has an outcome that nobody is happy with. As a starting point, printing the numbers with MiB/GiB units, but do we want to change other things, like avoid printing the component IDs, mirror/component counts, etc ? </p> <p>Also, I note that <tt>&#45;H</tt> is already used by "<tt>lfs getdirstripe</tt>" to print the directory hash type, so if we want consistent options between these commands and/or make the "<tt>&#45;&#45;human&#45;readsble</tt>" available there, then we need a different option. Possibly a "short long option"! <tt>&#45;&#45;hr</tt>" in addition to the "long long option" "<tt>&#45;&#45;human&#45;readsble</tt>" would work, instead of trying to find a single letter?</p> <p>How about a summary section on top which describes the number of stripes and any specific layout conditions:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>&lt;file / directory&gt; is a (file|directory) with &lt;number of stripes&gt; with each stripe being &lt;size of stripes&gt;. This (file|directory) has a specific layout to assign (first|last|etc) &lt;size&gt; of data to these targets &lt;targets&gt; and &lt;size&gt; to these targets &lt;.. etc&gt;. This (file|directory) also utilizes &lt;features list&gt; features. </pre> </div></div> <p>&lt;features list&gt; could contain something like:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>compression with &lt;compression type&gt; at &lt;compression level&gt; data on metadata </pre> </div></div> <p>and anything else..</p> <p><tt>after that dump out a target list with any additional relevant parameters much like mysql does when listing data from a query</tt></p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>+-----------------------------------------------------------------+ | TARGET | SIZE | OBJECT ID | etc. +-----------------------------------------------------------------+ | MDT0000 | | NNNNNN | | OST0000 | 12345 | NNNNNN | | OST0001 | 12345 | NNNNNN | | OST0002 | 12345 | NNNNNN | +-----------------------------------------------------------------+</pre> </div></div> <p> </p> <p>What do you think?</p> <p>Example1: simple striped file</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># lfs getstripe -H test.11.0.root filename: test.11.0.root layout: stripes: 8 | stripe size: 1024MB | pattern: raid0 | stripe offset: 3 objectid: 65 | stripes: 8 | stripe size: 1024MB | targets: OST0000, OST00006, OST0005, OST0002, OST0001, OST0007, OST0004 objectid: 66 | stripes: 1 | stripe size: 1024MB | targets: OST0003 </pre> </div></div> <p>Colin, all I can say about turning the getstripe info into a paragraph of text is "yuck", I don't ever want to do that. Not only does that hide the details among a bunch of filler words, it makes it much harder for non-English speakers to understand I think. </p> <p>I could imagine something like Peter's suggestion, one brief line per component, similar to the output of a "plain" layout on a directory - stripe count, component sizes, pools, maybe a compact list of OSTs, probably not even stripe size or object IDs are useful to most users. Like:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ lfs getstripe --hr file mirror: 1    component: 1, start: 0, end: 128KiB, mdt: 1, compress: gzip:9 component: 2, start: 128KiB, end: 1GiB, pool: ssd, stripes: 1, osts: 3 component: 3, start: 1GiB, end: 16GiB, pool: ssd, stripes: 4, osts: 4-7 component: 4, start: 16GiB, end: eof, pool: hdd, stripes: 40, unused mirror: 2 : </pre> </div></div> <p>The mirror, component, and attributes like compression, mdt, etc. would only be printed if needed, to reduce clutter and line length. A few times I wondered about using "part" instead of "component" (shorter, more common), but "part" has no meaning for a layout and I think would just add confusion.</p> <p>What this output does not need is to be parseable, nor "too pretty", or full text. We might consider to separate printing of numbers with units (like most "--human-readable" options do) and have a separate "<tt>&#45;&#45;plain</tt>" or "<tt>&#45;&#45;simple</tt>" option to control the skipping of uninteresting fields. </p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=adilger" class="user-hover" rel="adilger">adilger</a>... I like your "riff" on my earlier suggestion. Your suggestion of omitting unnecessary elements (e.g. mirror if there's only one) is elegant. I ponder if --json output would be better machine-parseable if that's needed.</p> <p>We already have a "<tt>lfs getstripe &#45;&#45;yaml</tt>" output option, and an "<tt>lfs setstripe &#45;&#45;yaml</tt>" option to consume that output. We don't need another machine readable format, this ticket is about having a <em>human</em> readable format. Anyway, I think JSON is ugly for humans because of the excess of quotes around everything, while YAML can be made both human and machine friendly.</p> <p>While my output looks similar to YAML, that is only because YAML was intended to be friendly for humans to read and use "normal" layouts. The output is not actually YAML, and shouldn't be used for anything except human consumption.</p> Development Rank 1|i03x27: Rank (Obsolete) 9223372036854775807 Severity