[LU-3569] Use real OST index as ostid_to_fid() parameter instead of always "0"

• Type: Bug
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.6.0, Lustre 2.8.0
• Affects Version/s: Lustre 2.5.0
• Severity: 3
• Assignee: nasf (Inactive)
• Reporter: nasf (Inactive)

Description

Currently, the callers for ostid_to_fid() always use "0" as the "ost_idx" parameter. There are potential issues for that, and may cause FID inconsistency as to crash the system.

Issue Links

• is related to: LU-8898 Interop conf-sanity test_52 FAIL: ll_recover_lost_found_objs failed
• is related to: LU-4414 ostid_id() returns incorrect OID for IDIF FIDs
• is related to: LU-4232 MDT and OST should validate incoming FIDs belong to local target
• is related to: LU-7585 Implement OI Scrub for ZFS

Comments

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/16477/
Subject: LU-3569 utils: remove ll_recover_lost_found_obj
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 8f810496b9b13b79018b6889939a6de6e19ddddd

[nasf (Inactive)]

Peter, I have refreshed the patch http://review.whamcloud.com/#/c/16477/

[Peter Jones]

Fan Yong

We have been discussing this issue on the triage call and it looks like an fsck issue. Could you please look at the latest feedback in the patch and see what needs to be done?

Thanks

Peter

[Gerrit Updater]

Lai Siyao ([e-mail]) uploaded a new patch: http://review.whamcloud.com/16477
Subject: LU-3569 utils: remove ll_recover_lost_found_obj
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: ef14f2f062ee31302d55a0a29ecee94233f47aa8

[Peter Jones]

As per discussion on the triage call, let's just delete the tool for 2.8

[Andreas Dilger]

Lai, I'd be grateful if you could revive my http://review.whamcloud.com/7880 patch to fix ll_recover_lost_found_objs, or possibly better is to make a different patch to delete ll_recover_lost_found_objs.c entirely because LFSCK should handle that now (sanity-scrub test_14 tests this).

[Lai Siyao]

Andreas, is there anything needed for this ticket?

[Andreas Dilger]

Looks like I am mistaken. I thought that it was a bug for ll_recover_lost_found_objs checking fid_seq_is_idif() and creating the object path LPX64, since this would move objects to "O/0x0/d*" instead of "O/0/d*". However, I didn't notice until now that the old code is actually using LPX64i instead of LPX64, and LPX64i prints zero as "0" instead of "0x0".

Even so, I cleaned up the code a bit to consolidate where the seq_name is being generated into one place, and IDIF objects now use LPU64 for the seq_name to make the code more clear.

http://review.whamcloud.com/7880

[Andreas Dilger]

Even if we don't store the OST index into the on-disk LMA FID, we need to fix a couple of bugs in the ll_lost_found_objs.

[nasf (Inactive)]

I am thinking whether we will have the requirement to change OST-index in the future. If we have, then storing OST-index inside the IDIF will be trouble. Because for normal FID, OST-index is meaningless, the client can get the OST-index by checking FLD with the given FID. So as long as we can adjust the FLD correctly, then changing OST-index without breaking the system is easy.

Currently, because all the IDIF use 0-index, the OI scrub does not care about the OST-index. But if the up layer change the IDIF logic, means both LOD and OFD use the real OST-index, then OI scrub needs to the OST-index to rebuild the LMA and the /O tree. And before such conversion is completed, the system is un-accessable, it is not like OI scrub for MDT file-level backup/restore. Under the later one case, the system is still accessible during the OI scrub rebuilding the OI files. I am not sure whether OI scrub or the OSD should know the 'index' information or not.

[Di Wang]

Oh, unfortunately, we always store FID_SEQ_IDIF(without ost index) for all of OST objects since 2.4.0. So LFSCK have to fix it. Nasf?