[LUDOC-240] Include additional steps in "14.8.5. Restoring OST Configuration Files" for adding reformatted OST

• Type: Improvement
• Resolution: Unresolved
• Priority: Major
• Assignee: Lustre Manual Triage
• Reporter: Karl Merritts (Inactive)

Description

Recently there was a need to reformat a deactivated OST(on the MGS) and then bring it back into service. Instead of using writeconf, the procedure in the most recent manual was followed:
http://build.whamcloud.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.xhtml#section_kzs_pgt_tl

a few additional steps were needed:

After initially following the ops guide instructions for taking mountdata from another OST, which lead to OST mount failure since the mountdata file was left in a bad state, we revised the procedure as follows:

1. took mountdata from another OST, used xxd to generate ascii version, updated two OST references in the file (one index reference, the other the name string); copied the revised mountdata file to /CONFIGS on the newly formatted OST.

2. mounted the OST, ensured that it started ok

3. unmounted the OST, used xxd to update /O/0/LAST_ID (created by the previous mount) to match current MDT lov_objid value for this OST
mounted OST again

4. reactivated OST

I'll clean up the recommendation changes when I get a chance.

Comments

[VIKRAM BABASO JADHAV (Inactive)]

Karl, Please give me the exact content to add in manual so I will create patch accordingly.

[Jodi Levi (Inactive)]

Karl,
If you can create the patch to update the Lustre Manual based on (https://wiki.hpdd.intel.com/display/PUB/Making+changes+to+the+Lustre+Manual+source), I will ensure that the patch get reviews and keep an eye out for it until it lands. Let me know if you have any questions on creating the patch from the instructions and I can get someone to help with that.
Does this seem reasonable?

[Karl Merritts (Inactive)]

Jodi,
Is there anything we can do to help get these changes into the manual?

-Karl

[Peggy Gazzola]

A couple clarifications... The original dd from old mountdata to new did not include the conv=notrunc option (which was missing from earlier versions of the ops guide). This resulted in a truncated mountdata file, which caused an error on OST mount. So we invoked plan B to modify a copy from another OST as described above using xxd. The 'conv=notrunc' option in the more recent ops guide covers that issue. Presumably xxd could also be used to reset the flag field (from 0x62 to 0x2).

But RE LAST_ID, on a newly reformatted OST (assuming the original was trashed), the LAST_ID isn't created until the initial OST mount. We did not attempt to 'mkdir /O/0' and create LAST_ID. Instead we went through the sequence described here, to mount, allow LAST_ID to be created, unmount, modify it. I think the important piece here is to correct LAST_ID prior to reactivating the OST (to prevent massive numbers of pre-creates). The doc section 'Fixing a Bad LAST_ID on an OST' doesn't clearly cover this case.