Architecture - FIDs on OST

Summary
We introduce new fids on OST. Using FIDs to identify objects on OSTs needs to be compatible with the existing object IDs used in current Lustre releases. There are two areas that need to maintain compatibility - the numbering of the objects themselves, and their encoding into RPCs in order to communicate between clients and servers.

In order to avoid FID numbers conflicting with existing objects the old objects are mapped into the reserved IDIF namespace as discussed in Interoperability fids zfs, using the ost_idx as part of the IDIF sequence number to disambiguate otherwise identical object numbers on different OSTs.

For network protocol interoperability with existing OSTs and clients the FID numbers must be mapped onto the o_id and o_gr fields.

Definitions

 * fid: cluster-wide unique identificator
 * sequence: contiguous set of fids, all fids from given sequence belong to single specific node
 * fld: persistent sequence to node mapping
 * object: OST object used to store user's data (what about internal to OST objects, like last_rcvd?)

Requirements

 * 1) any node can generate fids to be used for OST objects
 * 2) no orphans after partial recovery
 * 3) objects to be created on demand (CROW)
 * 4) backward compatibility?