[Lustre-discuss] Object index

DEGREMONT Aurelien aurelien.degremont at cea.fr
Wed Jul 25 03:14:29 PDT 2012

Le 24/07/2012 20:10, Daniel Kobras a écrit :
> Is this the troglodyte type of OST that started its life in times of prehistoric versions of Lustre? We see this on old files that were created in the early ages of Lustre 1.6, before the trusted.fid EA was introduced.
No, this filesystem was formatted with Lustre 2.0
By the way, does someone remember the incompatibility with 2.0/2.1 which prevent a target, formatted with Lustre 2.1 to 
be downgraded to Lustre 2.0 ?

> Other than that, these objects could have been preallocated, but never actually used. Do these objects contain any data at all (blockcount != 0)?
I was rather thinking of that. But I'm surprised that so many objects are preallocated.

>> -Some of them have good results, and the man page says that
>> "For objects with MDT parent sequence numbers above 0x200000000, this indicates that the FID needs to be mapped via the
>> MDT Object Index (OI) file on the MDT".
>> How do I do this mapping? I found some iam utilities but they do not seems to be ok, and I'm afraid IAM userspace code
>> has been deactivated.
> lfs fid2path (on any client) should do what you're looking for.
It does not. Moreover, lfs does not support this kind of fid

Lustre Manual said "The idx field shows the stripe number of this OST object in the Lustre RAID-0 striped file. "

Which seems true as I've got several files where idx > 0.
But, lfs fid sanity check is :
static inline int fid_is_sane(const struct lu_fid *fid)
                 fid != NULL &&
                 ((fid_seq(fid) >= FID_SEQ_START && fid_oid(fid) != 0
&& fid_ver(fid) == 0) ||

And so complains when fid_ver != 0

I'm not sure at all lfs fid2patch expect fid coming from OST.

>  From my experience, a small amount of object leakage is not too uncommon on real-world systems, so if lfs find doesn't show up any objects anymore, most likely you're good to take this OST down.
I agree on that, but I consider that more than 4k objects is not "a small amount" :)

> (Hey, and you can double-check with rbh-report --dump-ost, of course! ;-)
Sure, but I did not have an rbh DB for that FS available (a pity as "rbh-report" is few minutes in worst cases, "lfs 
find" was 15 hours :))
By the way, using a Lustre tool helps me to be sure the remaining objects were not related to a possible robinhood bug :)


More information about the lustre-discuss mailing list