HongChao, can you please make a patch for this, preferably with a test case. You can add a CFS_FAIL_LOC() check to set fid_seq=0 or similar to trigger the LASSERT(), then verify your patch fixes it.
Based on further analysis of the problem, it seems we can't verify fid_is_sane() directly in osp_sync_llog_init() since the logid is not yet converted to a FID. If llog_osd_open() checks fid_is_sane() and returns -ENOENT if it isn't sane:
if (logid != NULL) {
logid_to_fid(logid, &lgi->lgi_fid);
if (!fid_is_sane(&lgi->lgi_fid)) {
CERROR("%s: bad FID "DFID" in %s idx: rc = %d\n",
ctxt->loc_exp->exp_obd->obd_name,
PFID(&lgi->lgi_fid), -ENOENT);
RETURN(-ENOENT);
} else {
/* If logid == NULL, then it means the caller needs
then this return code is checked in osp_sync_llog_init() and the llog will be recreated:
rc = llog_open(env, ctxt, &lgh, &osi->osi_cid.lci_logid, NULL,
LLOG_OPEN_EXISTS);
/* re-create llog if it is missing */
if (rc == -ENOENT)
logid_set_id(&osi->osi_cid.lci_logid, 0);
Hi Andreas,
How about calling 'logid_to_fid" in osp_sync_llog_init after getting the logid from "CATALOGS" file, then check whether it is sane?
Sure, that would also work, and is also much more direct.
There is a bit of a question in my mind whether logid may not be a FID in some cases (e.g. upgrade from some very old system), but I don't think that is true anymore. This compatibility was needed for old filesystems when they were upgraded from pre-2.4 
Lustre, but all of these old systems should be gone at this point, or are never upgrading.
After fixing the current LASSERT issue, it might make sense to look at the use of llog_logid in the code and update it to use lu_fid wherever possible, by converting the llog_logid into lu_fid immediately and only passing the FID around. The next step would be to add a new LLOG_LOGFID_MAGIC that only stores the lu_fid to the catalog, start using it after some delay (with OBD_VERSION_CHECK() and/or backport code to LTS to read LLOG_LOGFID_MAGIC records and convert into llog_logid to minimize code change but still allow upgrade/downgrade to work) and then eventually we can remove llog_logid.
as per the dump of the "CATALOGS", the content of the "llog_catid" is
000020 0000000400000068 0000000000000000 000030 0000000000000000 0000000000000000
the OID field is "0x400000068", but is truncated to "0x68" during assigning it to lu_fid.f_oid(32bits).
the data seems to be a normal FID (f_seq=0x400000068, f_oid=0, f_ver=0)
the OID field is "0x400000068", but is truncated to "0x68" during assigning it to lu_fid.f_oid(32bits).
the data seems to be a normal FID (f_seq=0x400000068, f_oid=0, f_ver=0)
No, the 0x400000068 field is the oi_id field (mapped to f_oid), and the f_seq field is 0x0, which is what triggers the LASSERT. Valid records look like the following with oi_seq = f_seq = 0x1 = FID_SEQ_LLOG:
000080 00000000000004ef 0000000000000001 000090 0000000000000000 0000000000000000
In this case, the FID is [0x1:0x4ef:0x0] and would map to object O/1/d15/1263 on the MDT.
Hongchao Zhang (hongchao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36998
Subject: LU-13061 osp: check catlog FID after reading in
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 7a5df8c9c0fa2cab2135e68e305a9a850263d720
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36998/
Subject: LU-13061 osp: check catlog FID after reading in
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 4597fa7d884de0f1a1b030052d4d34983fed6109
Landed for 2.14
Minh Diep (mdiep@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37185
Subject: LU-13061 osp: check catlog FID after reading in
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: 0d2e23757ef6663f8b06b935253835937d8ca1f3
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/37185/
Subject: LU-13061 osp: check catlog FID after reading in
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 055eab6bd4c29bc961a10824ffa44323cce7640c