Update or improvement to a Lustre man page or documentation
(LU-930)
|
|
| Status: | Reopened |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Technical task | Priority: | Minor |
| Reporter: | Andreas Dilger | Assignee: | WC Triage |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | cdwgbl, easy, lad23dd | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Rank (Obsolete): | 11811 | ||||||||||||||||||||||||||||||||||||
| Description |
|
I'd like to split up the lfs(1) and lctl(8) man pages because they are huge and unwieldy, and as a result I think each of the sub-commands is given too little space for its description, arguments, and examples. It is also confusing to separate the synopsys, description, and examples for each of the sub-commands. Finally, we couldn't clearly describe the availability of each sub-command.for changes to make the various Lustre man pages more complete and consistent. There should be a single page of the form lfs-getstripe.1 or lfs-df.1 for each sub-command. In some cases, very similar commands may share a single page, but e.g. lfs-setstripe.1 should reference lfs-getstripe.1 so that it can be found easily. In particular, I'd like the man pages to follow the simple nroff style of using ".I", ".B", ".IR", ".BR" so that function names, option flags, and other explicitly specified strings are bold, user-supplied arguments and variables are italic, and delineators are regular text: .SH SYNOPSIS .B lfs_migrate .RB [ -c | -s ] .RB [ -h ] .RB [ -l ] .RB [ -n ] .RB [ -y ] .RI [ file | directory ...] Each man page should have the standard sections: SYNOPSIS
- one-line summary of command
- optional one-line summary of aliases
DESCRIPTION
- good description of what the command does
OPTIONS
- describe all options and their arguments
ENVIRONMENT
- optional section to describe environment variables affecting behaviour
RETURN VALUES
- describe return values and their causes
ERRORS
- optional section for API man pages (section 3) to describe return values like:
[ERRNO] description of error
EXAMPLES
- real-world usage examples
KNOWN BUGS
- optional section to list any known bugs
AVAILABILITY
- that it is part of lustre(7)
- which Lustre release it appeared in
SEE ALSO
- other man pages referenced by this one
- related Lustre and non-lustre commands/man pages
References to other commands' man pages should be in the form .BR lfs (1) See http://www.schweikhardt.net/man_page_howto.html for more examples |
| Comments |
| Comment by Justin Miller (Inactive) [ 28/May/14 ] |
|
I've written a new man page for lctl-network and wanted to get your feedback before I write too many more. I did my best to use the IEEE Std. 1003.1 for formatting arguments. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html I pulled together as much information as I could from documentation, testing the command, and source code, while still trying to be succinct. I do think that the idea of a man page for each subcommand is the best course. Otherwise, if you tried to organize by Network/Device/LFSCK, you would be basically recreating the Operations Manual. How should new man pages be submitted for review? If it is just like source code changes I can get Josh Walgenbach to show me. |
| Comment by Justin Miller (Inactive) [ 29/May/14 ] |
|
Updated with 'configure|unconfigure' |
| Comment by Andreas Dilger [ 30/May/14 ] |
|
Hi Justin, One thing I noticed is that the existing usage (and recommended in this bug until moments ago) of Lustre(7) is broken and lustre(7) needs to be used instead, since man is case sensitive. It seems to be missing a description of the "lctl --net o2iblnd some_lnet_command" style of usage to specify an LND type for later commands. While in some aspects it makes sense to include that as an option to the other LNet commands, rather than as part of the "lctl-net" command (it is useless if run just by itself), it might still be good to include a list of the different LND types so this can be updated in one place, and then referenced by other LNet-related sub-commands. If at all possible, it makes sense to try and keep the patches independent as much as possible, so that they can be inspected, tested (a requirement for all patches even though these patches are unlikely to cause problems), refreshed as needed, and landed without affecting all of the other patches you are working on. In this case, it might make sense to plan your work a bit so that this can be done more easily:
|
| Comment by Andreas Dilger [ 30/May/14 ] |
|
PS: in a related note - the "lctl network" usage message also seems incomplete and could be improved slightly as part of the patch for the man page. Don't feel obligated to do that if you don't want, but I thought if you are already taking time to investigate the options it might make sense to do this. |
| Comment by Gerrit Updater [ 06/Sep/16 ] |
|
Andreas Dilger (andreas.dilger@intel.com) uploaded a new patch: http://review.whamcloud.com/22324 |
| Comment by Gerrit Updater [ 26/Sep/16 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/22324/ |
| Comment by Peter Jones [ 26/Sep/16 ] |
|
Landed for 2.9 |
| Comment by Andreas Dilger [ 27/Sep/16 ] |
|
Unfortunately, there is still a bunch more work to be done here. |
| Comment by Andreas Dilger [ 09/Dec/16 ] |
|
The lfs setstripe command is already being handled by the PFL project: https://review.whamcloud.com/18596 |
| Comment by Andreas Dilger [ 09/Dec/16 ] |
|
The patch https://review.whamcloud.com/24228 " |
| Comment by Gerrit Updater [ 15/Dec/16 ] |
|
Steve Guminski (stephenx.guminski@intel.com) uploaded a new patch: https://review.whamcloud.com/24371 |
| Comment by Gerrit Updater [ 24/Jan/17 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/24371/ |
| Comment by Peter Jones [ 24/Jan/17 ] |
|
Landed for 2.10 |
| Comment by Steve Guminski (Inactive) [ 24/Jan/17 ] |
|
The recently landed patch is only the first of several patches required to address this ticket, so I've reopened it. |
| Comment by Gerrit Updater [ 23/Feb/18 ] |
|
Andreas Dilger (andreas.dilger@intel.com) uploaded a new patch: https://review.whamcloud.com/31406 |
| Comment by Gerrit Updater [ 15/Mar/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/31406/ |
| Comment by Gerrit Updater [ 17/Jun/19 ] |
|
Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35242 |
| Comment by Gerrit Updater [ 30/Jul/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35242/ |
| Comment by Gerrit Updater [ 30/Jul/19 ] |
|
Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35649 |
| Comment by Gerrit Updater [ 04/Oct/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35649/ |
| Comment by Tim Day [ 10/Mar/23 ] |
|
State of man pages (for lfs) right now, by my estimation:
Some of the pages need to be split up. Some new ones need to be created. And some stubs should be made for the trivial commands, so "lfs help" will have a page to show (in the future). |
| Comment by Andreas Dilger [ 10/Mar/23 ] |
|
Note that "lfs mv" is an alias for "lfs migrate -m", so should be a stub for that. |
| Comment by Andreas Dilger [ 19/Sep/23 ] |
|
It's also not clear that "lfs- |