[LU-17155] Simplify the output of lfs getstripe

• Status: Open
• Project: Lustre
• Type: New Feature
• Priority: Trivial
• Reporter: Colin Faber
• Assignee: Vitaliy Kuznetsov
• Resolution: Unresolved
• Severity: 4

Description

Let's try and simplify the output of lfs getstripe so that it's easier to read and understand the components involved.

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.

Comments

[Andreas Dilger]

Before any development is done on this, pbojanic_wc and cfaber 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 ?

Also, I note that -H is already used by "lfs getdirstripe" to print the directory hash type, so if we want consistent options between these commands and/or make the "--human-readsble" available there, then we need a different option. Possibly a "short long option"! --hr" in addition to the "long long option" "--human-readsble" would work, instead of trying to find a single letter?

[Colin Faber]

How about a summary section on top which describes the number of stripes and any specific layout conditions:

<file / directory> is a (file|directory) with <number of stripes> with each stripe being <size of stripes>. This (file|directory) has a specific layout to assign (first|last|etc) <size> of data to these targets <targets> and <size> to these targets <.. etc>. This (file|directory) also utilizes <features list> features.

<features list> could contain something like:

compression with <compression type> at <compression level>
data on metadata

and anything else..

after that dump out a target list with any additional relevant parameters much like mysql does when listing data from a query

+-----------------------------------------------------------------+
| TARGET    | SIZE  | OBJECT ID | etc.
+-----------------------------------------------------------------+
| MDT0000   |       | NNNNNN    | 
| OST0000   | 12345 | NNNNNN    |
| OST0001   | 12345 | NNNNNN    | 
| OST0002   | 12345 | NNNNNN    |  
+-----------------------------------------------------------------+

 

What do you think?

[Peter Bojanic]

Example1: simple striped file

# 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

[Andreas Dilger]

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. 

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:

$ 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
    :

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.

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 "--plain" or "--simple" option to control the skipping of uninteresting fields. 

[Peter Bojanic]

adilger... 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.

[Andreas Dilger]

We already have a "lfs getstripe --yaml" output option, and an "lfs setstripe --yaml" option to consume that output. We don't need another machine readable format, this ticket is about having a human 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.

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.