Details
-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
3
-
9223372036854775807
Description
It looks like lgl_oi.oi_fid is used in quite a number of places, but any use of lgl_oi.oi_fid looks to be incorrect (f_seq and oi_seq are in opposite order in struct ost_objid). This was broken by patch https://review.whamcloud.com/25640 "LU-9153 llog: update llog print format to use FIDs". It is only using oi_fid like PFID(&...lgl_oi.oi_fid), so this is only affecting error messages and not any functionality.
log_process_thread()) lfs02-MDT001e-osp-MDT0000: [0x3:0x1b70:0x4] Invalid record: index 16123 but expected 16122
The output "[0x3:0x1b70:0x4]" should be interpreted as FID [0x400001b70:0x3:0x0] (swap last and first components of the field, add intervening "0000" and add ":0x0" at the end) in the update_log_dir/ directory.
To print these FIDs correctly, there is a logid_to_fid() helper with the DOSTID macro, and it would make sense to have it also return the same pointer as the passed-in fid argument, so that it can be passed directly to PFID() in the error message, like:
struct lu_fid tmp_fid; CERROR("%s: "DFID" Invalid record: index %u but expected %u\n", loghandle2name(loghandle), PFID(logid_to_fid(&loghandle->lgh_id, &tmp_fid)), rec->lrh_index, index);
Alternately, it would be more efficient to add a new PLOGID() macro that is returning oi_seq, oi_id, 0, directly, and avoid the need for tmp_fid entirely.