[LU-19480] FLR-EC: Parity stripe count from data stripe count

• Type: Technical task
• Resolution: Unresolved
• Priority: Medium
• Severity: 3
• Assignee: Ronnie Sahlberg
• Reporter: Patrick Farrell

Description

This change adds automatic calculation of parity stripe counts for erasure-coded (EC) layouts.

Right now, the code ignores how many parity stripes should exist and leaves the parity component stripe counts unset (zero). This means layouts don’t reflect the actual number of parity stripes implied by the data configuration.

With this update, the LOD layer will compute the correct parity stripe count whenever an EC layout is created. The calculation is:
parity_stripes = ceil(data_stripes / k) * p
 
where k is the number of data stripes per RAID set (dstripe_count) and p is the number of parity stripes per RAID set (cstripe_count).
If the data stripe count isn’t a multiple of k, the result is rounded up so that all data stripes are covered. The final number is also limited by the number of available OSTs.

Example: with 10 data stripes and a 6+2 EC layout, we get ceil(10 / 6) = 2 RAID sets, each with 10 / 2 = 5 (total 2 × 5 = 10) data stripes, and 2 (total 2 × 2 = 4 parity stripes.

The total parity stripe count is set automatically on the server side — users can’t specify it directly. If the computed count can’t be satisfied due to OST limits, the system should handle it cleanly (either clamp or error).

Tests should confirm correct calculation across common EC configurations (e.g., 6+2, 4+2, 8+3, 2+1), including uneven data stripe counts and OST limit cases.

This ticket only covers the stripe calculation logic, not I/O or client-side API changes.

Issue Links

• is related to: LU-12187 FLR-EC: erasure coding layout handling