Architecture - Migration (2)

Note: The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.

Summary
Migration is a process of data and metadata moving within one cluster (one namespace) as well as to/from external non-Lustre storage servers. HSM, free space balance, file restriping are examples of migration.

Definitions

 * Agent : actually copies objects
 * Feed : object enumeration
 * Feed Generator: produces object enumeration for migration agent
 * Coordinator : menages migrations and running migration agents
 * Initiator: initiates a migration, issues a migration request

Quality Attribute Scenarios
Simple migration

duplicate requests are merged

conflicting requests abort in-progress migration

coherent access to moving objects

Empty UC

Implementation details

 * IMP1 all IO involving Lustre servers uses client API (exploit existing locking and sync LLITE infrastructure)
 * avoid reimplementing client
 * IMP2 separate problem into coordinators and agents
 * agents have datamover plugins
 * IMP3: pull model if target is Lustre OSD (run agent on sink)
 * IMP4: if target is Lustre OSD, send all requests to target (block client requests until they can be filled on target). source OSD must redirect
 * let MDTmaintain the redirection, in line with flash cache
 * callback layout (stripe descriptor) when we initiate migration, sends
 * blocking asts to all clients with any locks on the file
 * 3 phase: old layout, dual layout, final layout
 * IMP5: need a lock bit for layouts
 * means we need to drop the client lock when we flush inode
 * IMP6: creation of target object results in llog entry with old and new EA (SOM-style recovery)
 * IMP7: record (llog) and execute trunc/punch on tgt, propagate to source
 * IMP8: bit (or extent log) on MDT (master copy) indicating copy or tape is current ("can I reclaim this space?") 1 llog of extents indicating which files are on tape (for fast space reclamation). Similar to WBC on clients
 * IMP9: Use commit CB on EA with tape FID to tell the tape "not an orphan" (i.e. "we're counting on this tape fid")
 * IMP10: MDS inode objects never change fids
 * IMP11 locks a migrator might take automatically interact with locks other clients may take