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?

Use Cases

ID	Quality Attribute	Summary
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

QAS template

Scenario:
Business Goals:
Relevant QA's:
details	Stimulus source:
	Stimulus:
	Environment:
	Artifact:
	Response:
	Response measure:
Questions: