[LU-10169] Spillover space

• Type: New Feature
• Resolution: Fixed
• Priority: Minor
• Affects Version/s: Lustre 2.10.1
• Assignee: Patrick Farrell (Inactive)
• Reporter: Nathan Rutman

Description

I had an alternate but somewhat overlapping thought to LU-10070 - keep the last component going to EOF, but allow for the possibility of bounding it in the future by creating a new FLR replica, and marking the original one as stale.

Spillover space (MRP-4598):
I'm wondering if we can take the new enhanced file layouts feature plus OSC space grant info (or some other trigger) to eliminate ENOSPC caused by full OSTs. The idea would be something like:
1. Server decreases grants as space approaches 0
2. Client notes grant = 0 (or low)
3. Client takes layout lock, forcing flush of all dirty extents
4. Client adds a new FLR replica which chooses a different (emptier) set of OSTs for all further file extents of open-for-write files
5. Client sets this new layout as primary, and releases layout lock
6. Clients reqacquire locks and grants from new OSTs

Example

Initially:
Layout v1: [0-inf) OST0-4

Runs out of space when file is at 10GB; we add a 2nd replica with a PFL layout

Layout v2: complex
Replica1: [0-inf) OST0-4
Replica2: component1 [0-10GB) OST0-4; component2 [10GB-inf) OST5-10
Set Layer2 as the primary copy, mark Layer1 as stale.

Benefits

• Eliminate ENOSPC for single full OST
• Allow for "tiering" spillover from flash pool to disk pool
• Maybe use something like this also for changing layouts for failed OSTs...??

Questions

• Can layouts for open-for-write files be changed like this?
• Can the PFL component layout match object-for-object the original simple RAID0 layout? (I.e. we don't want to copy the data, but instead just reference the original objects, now with an extent limit.)
• Is grant the right trigger?
• Do we need a policy for spillover selection? Pre-set spillover targets? Ask the MDS for new allocation?

Issue Links

• is related to: LU-10070 PFL self-extending file layout