[LU-13527] allow OST FID lookup via lfs fid2path

• Status: Open
• Project: Lustre
• Type: Improvement
• Priority: Major
• Reporter: Andreas Dilger
• Assignee: WC Triage
• Resolution: Unresolved
• Labels: medium

Description

It would be useful to allow reverse pathname lookup of OST FIDs via "lfs fid2path /mntpt <fid>", since the OST FIDs are sometimes referenced in console error messages, and it is useful to be able to do a pathname lookup without first having to manually run e.g. "debugfs -c -R 'stat <O/<f_seq>/d$((<f_oid> %32))/<f_oid>' /dev/<ostdev>" or "ll_decode_filter_fid" on the underlying OST.

The client would need to first determine that this is an OST FID from the FLDB, then fetch the "fid" xattr that contains the MDT parent FID from the OST object (if it exists), and then do the normal fid2path lookup on the returned MDT parent FID.

Issue Links

• is related to: LU-11638 lfs fid2path should list open-unlinke...
• is related to: LU-13124 lfsck check for multiple linked file ...

Comments

[Andreas Dilger]

It should be possible to make a decision in __ll_fid2path() whether to call OBD_IOC_FID2PATH on the LMV/MDC export or the LOV/OSC export based on the FID being requested. There would need to be handling of OBD_IOC_FID2PATH in lov_iocontrol() and osc_iocontrol() and then something similar to mdc_ioc_fid2path() to call obd_get_info(KEY_FID2PATH) to send the RPC to the OST.

On the OST side, handling of KEY_FID2PATH would be needed in ofd_get_info_hdl() to extract the MDT FID from the OST object and return it in back to the client. While it isn't strictly required (there will not be any pathname returned), it makes sense to use struct getinfo_fid2path for the OST RPC so that it is handled consistently with the MDT RPC.

Then the client can extract the MDT FID from the OST reply and execute the rest of the __ll_fid2path() operation as it does today.