Hide Forgot
Need to integrate the kbase article "How do I gather GFS lockdump information from RHEL 5 to send to Red Hat Support?" into official product docs. Link to kbase article: https://access.redhat.com/kb/docs/DOC-19449
Some notes: 1. for RHEL6 and up, the gfs2_tool gettune command should be replaced with checking the data in /proc/mounts which is much less likely to get stuck if the system is in an odd state, and also is a much better source for such information. 2. If the GFS2 hangalyzer doesn't work, the lock dumps can be obtained manually by using the debugfs file directly. It should be noted as well that using large buffer size in this operation will speed it up considerably when large numbers of glocks are involved, so using dd to copy the information is a much better solution, since bs can be set to something suitably large (e.g. 4M). Otherwise the info looks good to me.
This is an issue for the GFS manual, so it should have been assigned to me. This is the first I'm seeing it, though, and it's past the end of the 5.8 development phase so I'm moving this to 5.9.
Steve: As for point 1: This Bug is for RHEL 5. We cover this to some extent for RHEL 6, with the new documentation for gfs2_tool gettune, but I think I'll clone this for RHEL 6 as a placeholder to check (for the next release) if there's any information in here we don't cover in the RHEL 6 document that we should.
Since I first looked at the article in question a few weeks ago (and printed it out and started to work on integrating it into the GFS document), the article has been updated. So apparently this is a moving target, which makes me question why we are moving it into the GFS documentation and away from kbase -- once it's in the GFS doc it can't be updated at will quite so readily. In any case, I need to recheck this article again when I close this bug (and we remove the article from kbase), to be sure I have all the updates. So I have "subscribed" to the article, and I will be adding Shane Bradley and Adam Drew to the review list for when I integrate the article into the GFS docs -- Shane is the current owner of the document, and Adam made the most recent updates.
We have GFS and GFS2. GFS is only in RHEL 4 and RHEL 5 and has been largely replaced by GFS2. GFS is no longer being developed. That doc, https://access.redhat.com/kb/docs/DOC-19449, is for GFS only. Integrating the information in that doc into the GFS docs may make sense but I think it would be an effort that would benefit fewer customers than adding diagnostic information into the GFS2 docs. If we decide instead to concentrate on GFS2 (which makes sense in my opinion) you'd want to incorporate this doc: "What data do I gather if processes accessing GFS2 are hung?" https://access.redhat.com/kb/docs/DOC-42333 Additionally (and I'll let Steve weigh in on this) I think there's a case to be made that we may want to package that simple data gathering script I wrote along with gfs2-utils so that customers have the data gathering tool on their system by default. I'll be happy to help in any way I can.
Just noticed this bug is for GFS and 712391 is for GFS2. Please ignore my last comment. I'll update that bug. Though we may want to come up with a simpler procedure such as a script that does everything the customer needs - DOC-19449 is not something I'd want to go through during a production outage... there's a lot of steps there.
Adam: I've gotten as far as gathering the text for formatting and looking over the GFS procedure here, and my first pass thought was not only that it does seem like a lot of steps, but it makes many references to other kBase articles (which is not something that, in general, is not a good idea for the published documentation) and figuring out how to address those kBase references in the GFS document will be an issue (simply adding all those referenced procedures in detail seems well beyond the scope of the GFS manual). For the moment, then, I'll work on the GFS2 document first and after the shutdown I'll come back to this, perhaps starting an email discussion about your question here, to see if this article is in fact what we want to add at this point to the GFS document. In other words, it looks as if this probably needs at least a little bit of discussion anyway before I add it (as is) to the GFS manual.
Correction to "Comment 7" -- a bad re-editing repeated the word "not": "it makes many references to other kBase articles (which is not something that, in general, is not a good idea for the published documentation)" Obviously what I meant was that as a matter of policy we don't reference specific kBase articles in the published docs, since you can't really maintain the links. In theory, if the information is necessary for the product, we should be incorporating it into the doc when possible. Or at least that's my understanding.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.