-
Technical task
-
Resolution: Done
-
Medium
-
None
-
3
-
9223372036854775807
Parity/EC mirrors need to be tightly coupled to the specific data mirror they were created to match; otherwise, they cannot provide proper redundancy due to mismatches in stripe_size, stripe_count, component extent, or possibly overlapping OST selection. If they are not linked, the stripe allocation will not correspond correctly between data and parity components and may result in data loss if an OST object is unavailable and EC data recovery is needed.
To accomplish this, we must store the mirror ID of the data mirror in each of the corresponding parity components.
We need 16 bits to represent the mirror ID. To accommodate this, we’ve selected the LLC timestamp field, which is currently a 64-bit field that is set and printed but not actually used for functional purposes. We can repurpose the upper 16 bits of this field to store the mirror ID of the data mirror associated with each parity mirror.
- is duplicated by
-
LU-19546 Tight binding between erasure code and parity mirrors
-
- Closed
-
- is related to
-
LU-19525
FLR-EC: Prevent stranding of parity mirror
-
- Open
-
-
LU-12187
FLR-EC: erasure coding layout handling
-
- In Progress
-
-
LU-19527
FLR-EC: Never select EC mirror as primary for write or allow setting PREFER flags
-
- Resolved
-
-
LU-19066 FLR2: identify rack/PSU failure domains for servers
-
- Reopened
-