Architecture - FIDs on OST
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.
- cluster-wide unique identificator
- contiguous set of fids, all fids from given sequence belong to single specific node
- persistent sequence to node mapping
- OST object used to store user's data (what about internal to OST objects, like last_rcvd?)
- any node can generate fids to be used for OST objects
- no orphans after partial recovery
- objects to be created on demand (CROW)
- backward compatibility?
|new sequence||usability, performance||client gets sequence from specific OST|
|create file||usability||create file on MDS with specified objects|
|space balance||usability,performance||how to distribute objects among OSTs|
|file exists||usability||create file request finds existing file|
|reconnect||availability||reconnect after OST failover|
|2.0||usability||compatibility mode: MDS talks to OST to get new fids|
|2.x||usability||clients talk to OST to get new fids|
|orphan||availability||server should be able to identify orphan objects|
Quality Attribute Scenarios