LL_DECODE_FILTER_FID(8)

💅 LL_DECODE_FILTER_FID(8) — the Lustre Configuration Utilities girlies know

okay so bestie, you're in the LL_DECODE_FILTER_FID(8) part of the Lustre Configuration Utilities, and honestly? this one is a little forensic queen. she shows you the Lustre Object ID and the MDT parent FID for your OST objects, and she's not even sorry about it. 💖

---

✨ NAME ✨

ll_decode_filter_fid — display Lustre Object ID and MDT parent FID 🎀

---

🌸 SYNOPSIS 🌸

ll_decode_filter_fid object_file [object_file ...]

---

🦋 DESCRIPTION 🦋

So ll_decode_filter_fid decodes and prints the Lustre OST object ID, the MDT FID, and the stripe index for the OST object(s) you point at. Where does that info live? In the "trusted.fid" attribute on each OST object, no cap. 😌 And the way you get access to that is by mounting the OST filesystem locally as type ldiskfs for maintenance — that's the vibe check you have to pass, she can't read it from anywhere else.

The "trusted.fid" extended attribute gets stored on each OST object the very first time it's modified (like, data written or attributes set) and after that, Lustre never touches it again — doesn't read it, doesn't modify it. She's frozen in time, an artifact. 🏛️

The OST object ID (objid) comes in clutch if your OST directory gets corrupted, though normally the

ngl bestie, the original page literally trails off there mid-sentence — "though normally the" — and I am NOT about to invent an ending for it. The lore ends when it ends. 💀

---

🔥 EXAMPLES 🔥

actual receipts, here's what it looks like in the wild:

root@oss1# cd /mnt/ost/lost+found
root@oss1# ll_decode_filter_fid #12345[4,5,8]
#123454: objid=690670 seq=0 parent=[0x751c5:0xfce6e605:0x0]
#123455: objid=614725 seq=0 parent=[0x18d11:0xebba84eb:0x1]
#123458: objid=533088 seq=0 parent=[0x21417:0x19734d61:0x0]

So what is this telling us, bestie? This shows that the 3 files in lost+found have decimal object IDs 690670, 614725, and 533088, respectively. And the object sequence number (which used to be called the object group, for the oldheads 👵) is 0 for all current OST objects.

The MDT parent inode FIDs are hexadecimal numbers shaped like sequence:oid:idx. Since the sequence number is below 0x100000000 in all of these cases, these FIDs are living in the IGIF (legacy Inode and Generation In FID) namespace 💫 and they map directly onto the MDT inode = seq and generation = oid values. So that means the MDT inodes are 0x751c5, 0x18d11, and 0x21417 respectively. periodt.

But beware the plot twist: for objects with MDT parent sequence numbers above 0x200000000, that means the FID has to be mapped via the MDT Object Index (OI) file on the MDT to figure out the internal inode number. so if you're above that threshold, it's giving "you need to do more homework" ✨

And the idx field? That shows the stripe number of this OST object inside the Lustre RAID-0 striped file. striped file royalty. 🌈

---

🎀 AVAILABILITY 🎀

ll_decode_filter_fid is part of the lustre(7) filesystem package since release 2.0.0 — she's been iconic since day one. 👑

---

💜 SEE ALSO 💜

• lustre(7)

---

okay that's the whole page, you ate it, no crumbs left 🍓 stay safe out there decoding FIDs, and remember: this queen is from the Lustre package, dated 2024-08-28, manual page LL_DECODE_FILTER_FID(8). bye bestie, love u 💖🫶✨