kg.xu keguang · review.whamcloud.com

LU-7266 ldlm: introduce pressure-based SLV

Legacy SLV/CLV reacts to server pressure indirectly and can delay
lock reclaim. This change introduces a pressure-based SLV path:
server sends packed pressure in SLV, and client converts it to evict
quota.

Packed SLV Format:
 * Bits 63..60: format version (current 0x1). Legacy SLV leaves
   these bits clear.
 * Bits 59..16: reserved for future use.
 * Bits 15..0: pressure in hundredths of a percent, where 10000
   means 100.00%. Here pressure is total-grant-lock/total-limit.
   Unlike the previous grant-plan-based scalar SLV.

Rationale:
- Percentage-based eviction scales with client lock footprint, so
  larger lock holders evict more locks under pressure while smaller
  clients are not over-penalized.
- Gradual rollout is gated by packed-capable export coverage,
  avoiding a mixed-upgrade case where only a small subset of new
  clients absorbs repeated reclaim pressure.
- Client eviction uses segmented pressure-to-evict mapping, so
  reclaim is mild at low pressure and stronger at high pressure. At
  relatively low pressure, clients react faster to keep pressure in
  a healthy range; at higher pressure, clients use a longer evict
  interval because each round evicts more locks, reducing oscillation
  and avoiding over-evicting locks that should be retained; at or
  above the last curve point the interval shortens so high-pressure
  reclaim stays frequent.

Key updates:
- add OBD_CONNECT2_POOL_SLV_PACKED negotiation and packed SLV helpers
- add slv_mode (legacy_slv / pressure_rollout), rollout threshold,
  and client evict-curve sysfs controls
- pressure_rollout pools use ldlm.lock_pool_limit_mem_pct (default
  30% of RAM / LDLM_LOCK_MEM_OVERHEAD) instead of LDLM_POOL_HOST_L
- keep dual SLV state (legacy scalar + pressure scalar) for
  compatibility, where in pressure path; add quota-based client
  reclaim policy: ldlm_cancel_pressure_policy
- fall back to legacy_slv on mixed-filesystem server nodes
- keep legacy behavior for old clients and pre-threshold rollout
  stages
- add sanity-ldlm-pool.sh, sanity 124aa, and man pages for the new
  pool parameters

Performance impact:
CPU overhead should be negligible.
- The server recomputes pressure once per second per pool. On the
  client, pool recalc runs on the ~10s timer and when unused locks
  are decrefed.
- On the packed pressure path, reclaim no longer performs per-lock
  arithmetic during LRU scanning, so lock-heavy workloads should see
  unchanged or slightly lower CPU usage.

Assisted-by: Cursor:auto/codex5.5
Signed-off-by: Keguang Xu <squalfof@gmail.com>
Signed-off-by: Keguang Xu <kxu@ddn.com>
Change-Id: If8a6f247127576965ae45c349a4ab04fb286615a

LU-17493 mdc: restore LDLM cancel on blocking callback

In highly contended directories like ROOT/, /home, /projects,
abnormal clients holds LCK_PR executing 'ls' may block all
other operations. To prevent this, we can prioritize directory
modification responsiveness over strict readdir() cache coherency.
This approach is supported by the POSIX standard, which does not
require full cache coherency for readdir() across processes on the
same node (discussed in LU-3308).

A directory is considered 'contended' if it falls into one of the
following three categories:
1. Critical directories: essential system directories like
ROOT/, /home, and /projects.
2. Directories with racing locks: directories experiencing
significant lock contention can be identified by checking
ldlm_res_check_contention().

To improve performance in these situations, we can yield the CPU
during ll_iterate() -> xxx -> mdc_read_page() using the lock flags
LDLM_FL_CANCEL_ON_BLOCK and LDLM_FL_CANCEL_ON_CONTEND.
- Client-side: The client checks for conditions 1 and sets the
  LDLM_FL_CANCEL_ON_BLOCK flag.
- MDS-side: MDS has complete lock contention information, this could
  be used to set the LDLM_FL_CANCEL_ON_CONTEND flag on locks.
By setting these flags, the LDLM will release the 'ls' locks and
quickly grant other pending locks for modifications, ensuring a more
responsive system.

Note.1: ll_getattr() that satifies condiction 1&2 has been updated
accordingly as well. Since its lock:LCK_PR(UPDATE|PERM) encompasses
the lock:LCK_PR(UPDATE) required by ll_iterate(), it's preferrable
to set CANCEL_ON_BLOCK at the first place in ll_getattr(). Failing
to do so would result in this flag being absent from ll_iterate()'s
lock.
Note.2: we've leave ll_lookup as is. When ll_lookup() is invoked, it
lacks the necessary information (specifically, dir_depth) to verify
condition 1.

Signed-off-by: Keguang Xu <squalfof@gmail.com>
Change-Id: I90163f2bba64f7955cec0d538724ad363eed9abb

LU-20690 ec: verify parity against data, allow p > k

With the RAID10-like parity layout the p parities of a raidset share
one offset, so the parity of a component fits in its extent whatever
p is. Remove the p <= k checks in lfs and llapi; k+p <= 256 and
p <= 15 remain. Also drop the mirror-extend stripe_count < p guard
in ec_check_data_comp() so --ec 2+3 works on a two-stripe target.

An instantiated parity is checked against its data component in
lod_verify_ec_parity_comps() after lod_use_defined_striping() /
lod_parse_striping(), using lod_comp_find_linked() for the same
pairing rule as the allocator (covers layout-change replay). Require
a bidirectional link, matching k/p and stripe size, and parity stripe
count ec_raidset_count() * p. lod_verify_striping() checks k/p and
rejects an instantiated parity with stripe_count == 0 before
DEFINED object init.

Tests: sanity-ec 4a and 10 accept p > k, and 4b rejects k == 0 and
k > 255. 8m covers mirror extend --ec 2+3 on a two-stripe target.
300 covers PFL -E 2M --ec 2+3 create/resync/verify, and 305 covers
p > k multi-raidset create/resync/verify. llapi_layout_test test47
allows 3+4.

Test-Parameters: testlist=sanity-ec ostcount=8
Signed-off-by: Keguang Xu <kxu@ddn.com>
Assisted-by: Cursor:Composer llm_code_and_review_tools
Change-Id: I3878502e8ff739cb5ed420ff359e2008376303e7

LU-20690 ec: store EC parity like RAID10

The k >= p restriction is not a Cauchy/ISA-L limit. It comes from
storing parity as RAID0|PARITY: the p parity objects of a raidset are
concatenated along the file offset, so raidset_count * p * stripe_size
does not fit in a finite PFL extent when p > k (for example
--ec 2+3 -E 2M). This patch changes the parity layout; the p <= k
checks in lfs and llapi stay until a following patch removes them.

Store EC parity as LOV_PATTERN_PARITY instead. A raidset is an EC
split of the stripe set, and the layout is like RAID10 in that it has
the same two axes:

  - across the raidsets of one stripe set: like RAID0, one
    stripe_size per raidset;
  - within one raidset: like RAID1, the p parity stripes share one
    file offset (the same object_off).

The RAID1 axis comes from recovery. A raidset of k data and p parity
stripes survives the loss of any p of its k + p stripes, just as a
RAID1 of p + 1 copies survives the loss of any p copies. RAID1 is the
k == 1 case, where each parity is a copy of the data (--ec 1+N). The
p parities protect the same data, so they share its offset: the
offset says which data is protected, the parity index says which
redundancy unit it is.

What differs from RAID1 is I/O, not the role. For k > 1 the parities
are not replicas: each holds a different parity, and a lost stripe is
rebuilt from any k survivors rather than copied from one. The parity
uses the extent of the data component.

RAID0 places data rows from file offset 0, whereas counting EC rows
and raidsets from e_start groups the wrong k stripes when e_start is
not a multiple of the data stripe width: the stripes EC groups as one
raidset are not the objects lod paired with that raidset's parity
OSTs, and a degraded read rebuilds a lost stripe from the wrong
parity. For example -E 4M -c 1 -E eof -S 1M -c 8 --ec 4+1 puts offset
4M on object 4 (raidset 1), which counting from e_start encodes into
the parity of raidset 0. When e_start is not a multiple of
stripe_size, as after a 64K DoM component, counting stripe_size
parity slots from e_start also splits stripes at
e_start + n * stripe_size and overflows e_end.

Count rows and raidsets from file offset 0, as RAID0 maps the data
objects:

  row = off / (stripe_count * stripe_size)
  ec_off = O
      + (row - row of e_start) * raidset_count * stripe_size
      + raidset * stripe_size + off % stripe_size

Data before e_start is taken as zero, and so is its parity, which is
not stored: the origin O moves back from e_start over the raidsets of
the first row that end before e_start, and over the part of the
raidset of e_start below e_start % stripe_size when e_start is in its
last data stripe. slot % raidset_count stays the raidset, so the
parity OSTs lod pairs are unchanged, and every stored parity byte has
data in the component. Common DoM and PFL layouts with an unaligned
e_start are supported and keep their parity within [e_start, e_end),
such as:
- -E 64K -L mdt -E 1M -c 1 -S 1M -E eof -c 4 -S 4M --ec 4+2;
- -E 64K -L mdt -E 16M -c 2 -S 1M -E eof -c 4 -S 4M --ec 2+2;
- -E 64K -L mdt -E eof -c 4 -S 1M --ec 2+2;
- -E 1M -c 1 -S 1M -E 64M -c 1 -S 4M -E eof -c 4 -S 4M --ec 4+2.
When every raidset has one data stripe (--ec 1+N, or one data
stripe), there is one parity slot per data stripe and nothing to
pack, so rows and O count from file offset 0, as RAID0 does: ec_off
is the data offset, and each parity object is a copy of its data
object at the same object offsets, so it can stand in for it.
Otherwise O depends only on e_start, the data stripe count, k and the
stripe size, not on e_end, and when e_start is a multiple of the
stripe width, O is e_start.

Add ec_raidset_count(), ec_raidset_first(), ec_stripe_to_raidset()
and ec_off_to_raidset_offset() next to ec_split_stripes() in
lustre_user.h, and struct ec_parity_geom with ec_parity_geom_init(),
ec_data_to_parity() and its inverse ec_parity_to_data(), with
ec_parity_width() for the parity bytes of one stripe set, and use
them in lov, lod and llapi instead of open-coding the k0 * n0 split.
ec_parity_geom_init() also records the data row of parity slot 0 in
epg_row0 (0 for 1-data raidsets).
lov caches O in lsme_parity_origin when the layout is unpacked and
returns it from lsme_stripe_origin(), and lov_parity_geom_init()
fails a degraded read whose pair does not match in stripe size,
raidsets or origin; the parity mirror EOF of such a pair is also
bounded by one parity row per stripe set from e_start. Raidset
objects before e_start read as zero in degraded reads and resync.
A read is widened to whole raid sets, but not past the e_end of its
component, so a read ending there does not start an empty recovery
cycle for the next component's first raid set, which may begin before
its e_start.
lsme_parity_raid10() now just returns lsme_is_parity(), as every
parity component is LOV_PATTERN_PARITY, and
lsme_parity_slots_per_raidset() is dropped.

A component shorter than one stripe (e_end < e_start + stripe_size)
whose raidset continues past e_end (e.g. [64K, 1M) with -S 1M -c 2
--ec 2+2, or [1M, 4M) with -S 4M -c 2 --ec 2+2, where the second
stripe is never reached) still has no room for a full stripe_size
parity slot from e_start. ec_parity_fits() detects it:
llapi_layout_sanity() refuses it with LSE_EC_PARITY_FIT,
llapi_ec_check_comp_match() refuses to resync or verify it, and
lod_comp_prep_create() checks it again with the final data stripe
count, also for lfs mirror extend --ec.

The lov slot geometry, the STRIPE I/O scope and the per-stripe llapi
helpers were added by the previous patches and only take effect for
LOV_PATTERN_PARITY. This patch switches the encoding so they apply:
llapi_pattern_to_lov() and llapi_layout_to_lum() emit
LOV_PATTERN_PARITY, lov_pattern_supported() accepts it in place of
RAID0|PARITY (and lov_pattern_available() via that), and lod allocates
and verifies parity components with it. EC has not shipped, so the old
combination is not kept. Finite-extent stripe-count shrinking, now in
one lod_comp_shrink_to_extent() helper instead of three copies, is
skipped for parity components. lsm_unpackmd_comp_md_v1() and
lod_verify_striping() reject a component whose LCME_FL_PARITY flag and
LOV_PATTERN_PARITY disagree, since the parity geometry follows the
flag.

vvp_prep_size() no longer writes KMS into i_size for parity I/O.
ci_parity_eof is derived from i_size, and KMS is only a lower bound
of the data size, so a parity read within KMS shrank ci_parity_eof
for later parity I/O.

Userspace resync and verify move to the RAID10 offsets: one
stripe_size per raidset, each parity addressed by its stripe index,
leaving the part of the first parity slot below e_start alone. The
punch, zero-fill and hole verify of a parity slot are bounded by the
e_end of its component; no slot runs past e_end while
ec_parity_fits() holds, so this is only a defensive bound. Hole
punch-or-clear and hole verify loop over the p parity stripes that
share an offset when they fall back to zero-fill or zero-content
reads.

lfs setstripe --yaml parses the pattern as the comma-separated flags
lfs getstripe -y prints, so "parity,overstriped" keeps overstriping.

lfs mirror read of a parity mirror still dumps every parity object in
RAID0 order, through mirror_dump_parity() in lfs, from e_start.  The
dump of a component stops at its e_end: when the extent is not a
multiple of the data stripe set, the raid sets of the last row past
e_end hold the data of the next component.  The glimpse lock of such
a read spans every component, so lov_lock_sub_init() no longer
rejects a glimpse because a component the I/O does not cover has
fewer parity stripes than the designated one; lov_io_iter_init()
checks the components the I/O covers.

Example: -E 128M -c 11 -S 1M --ec 4+2

  data/parity extent [0, 128M)
  raidsets [4,2], [4,2], [3,2] (raidset_count=3)
  parity has 6 OST objects
  one data stripe set = 11M
  one parity stripe set = 3M (not 1M flat, not 6M concat)

  stripeset raidset data_pos    ec_off  concat  objects
  --------- ------- ----------- ------- ------- -------
  0         0       [0, 4M)     0       0       0,1
  0         1       [4M, 8M)    1M      2M      2,3
  0         2       [8M, 11M)   2M      4M      4,5
  1         0       [11M, 15M)  3M      6M      0,1
  1         1       [15M, 19M)  4M      8M      2,3
  1         2       [19M, 22M)  5M      10M     4,5

The concat column is what RAID0|PARITY would have used, and is what
overflows a finite extent when p > k.

Tests: sanity-ec 12c/12d/34c cover
holes and multi-raidset offsets, 30d and 31b-31e check the parity dump
size, 34d dumps a mixed-p mirror whose first extent is not a multiple
of the stripe set, 63d recovers reads from parity of raidset 1 in a
PFL component that does not start at 0, 301 covers an e_start that
stripe_size does not divide and checks that a component whose parity
would pass e_end is refused for that reason, 302 resyncs, verifies and
reads degraded common PFL layouts with an unaligned e_start, 303
recovers reads when e_start is not a multiple of the stripe width,
with equal and unequal raidsets, 304 covers zero-fill before e_start,
305 truncates at raidset and unaligned component boundaries, and 306
reads degraded across a component boundary where the raid set of the
first component runs into the next one.
llapi_layout_test asserts the component pattern is LLAPI_LAYOUT_PARITY
and 68 checks the parity placement over a range of geometries and
extents, and that 1-data raidset copies are at the data object
offsets.

Test-Parameters: testlist=sanity-ec ostcount=8
Test-Parameters: testlist=llapi_layout_test
Test-Parameters: testlist=sanity-ec ostcount=8 fstype=zfs
Signed-off-by: Keguang Xu <kxu@ddn.com>
Signed-off-by: Ronnie Sahlberg <rsahlberg@whamcloud.com>
Signed-off-by: Andreas Dilger <adilger@thelustrecollective.com>
Assisted-by: Cursor:Composer/Opus5.5 llm_code_and_review_tools
Assisted-by: ClaudeCode:claude-opus-5-5 ltvm llm_code_and_review_tools
Assisted-by: ClaudeCode:claude-fable-5-1 llm_code_and_review_tools
Change-Id: I9574df44969ddd40776f028b3c326d150ea08eb5

LU-20690 ec: verify parity against data, allow p > k

With the RAID10-like parity layout the p parities of a raidset share
one offset, so the parity of a component fits in its extent whatever
p is. Remove the p <= k checks in lfs and llapi; k+p <= 256 and
p <= 15 remain. Also drop the mirror-extend stripe_count < p guard
in ec_check_data_comp() so --ec 2+3 works on a two-stripe target.

An instantiated parity is checked against its data component in
lod_verify_ec_parity_comps() after lod_use_defined_striping() /
lod_parse_striping(), using lod_comp_find_linked() for the same
pairing rule as the allocator (covers layout-change replay). Require
a bidirectional link, matching k/p and stripe size, and parity stripe
count ec_raidset_count() * p. lod_verify_striping() checks k/p and
rejects an instantiated parity with stripe_count == 0 before
DEFINED object init.

Tests: sanity-ec 4a and 10 accept p > k, and 4b rejects k == 0 and
k > 255. 8m covers mirror extend --ec 2+3 on a two-stripe target.
300 covers PFL -E 2M --ec 2+3 create/resync/verify, and 305 covers
p > k multi-raidset create/resync/verify. llapi_layout_test test47
allows 3+4.

Test-Parameters: testlist=sanity-ec ostcount=8
Signed-off-by: Keguang Xu <kxu@ddn.com>
Assisted-by: Cursor:Composer llm_code_and_review_tools
Change-Id: I3878502e8ff739cb5ed420ff359e2008376303e7

LU-20690 ec: store EC parity like RAID10

The k >= p restriction is not a Cauchy/ISA-L limit. It comes from
storing parity as RAID0|PARITY: the p parity objects of a raidset are
concatenated along the file offset, so raidset_count * p * stripe_size
does not fit in a finite PFL extent when p > k (for example
--ec 2+3 -E 2M). This patch changes the parity layout; the p <= k
checks in lfs and llapi stay until a following patch removes them.

Store EC parity as LOV_PATTERN_PARITY instead. A raidset is an EC
split of the stripe set, and the layout is like RAID10 in that it has
the same two axes:

  - across the raidsets of one stripe set: like RAID0, one
    stripe_size per raidset;
  - within one raidset: like RAID1, the p parity stripes share one
    file offset (the same object_off).

The RAID1 axis comes from recovery. A raidset of k data and p parity
stripes survives the loss of any p of its k + p stripes, just as a
RAID1 of p + 1 copies survives the loss of any p copies. RAID1 is the
k == 1 case, where each parity is a copy of the data (--ec 1+N). The
p parities protect the same data, so they share its offset: the
offset says which data is protected, the parity index says which
redundancy unit it is.

What differs from RAID1 is I/O, not the role. For k > 1 the parities
are not replicas: each holds a different parity, and a lost stripe is
rebuilt from any k survivors rather than copied from one. The parity
uses the extent of the data component.

RAID0 places data rows from file offset 0, whereas counting EC rows
and raidsets from e_start groups the wrong k stripes when e_start is
not a multiple of the data stripe width: the stripes EC groups as one
raidset are not the objects lod paired with that raidset's parity
OSTs, and a degraded read rebuilds a lost stripe from the wrong
parity. For example -E 4M -c 1 -E eof -S 1M -c 8 --ec 4+1 puts offset
4M on object 4 (raidset 1), which counting from e_start encodes into
the parity of raidset 0. When e_start is not a multiple of
stripe_size, as after a 64K DoM component, counting stripe_size
parity slots from e_start also splits stripes at
e_start + n * stripe_size and overflows e_end.

Count rows and raidsets from file offset 0, as RAID0 maps the data
objects:

  row = off / (stripe_count * stripe_size)
  ec_off = O
      + (row - row of e_start) * raidset_count * stripe_size
      + raidset * stripe_size + off % stripe_size

Data before e_start is taken as zero, and so is its parity, which is
not stored: the origin O moves back from e_start over the raidsets of
the first row that end before e_start, and over the part of the
raidset of e_start below e_start % stripe_size when e_start is in its
last data stripe. slot % raidset_count stays the raidset, so the
parity OSTs lod pairs are unchanged, and every stored parity byte has
data in the component. Common DoM and PFL layouts with an unaligned
e_start are supported and keep their parity within [e_start, e_end),
such as:
- -E 64K -L mdt -E 1M -c 1 -S 1M -E eof -c 4 -S 4M --ec 4+2;
- -E 64K -L mdt -E 16M -c 2 -S 1M -E eof -c 4 -S 4M --ec 2+2;
- -E 64K -L mdt -E eof -c 4 -S 1M --ec 2+2;
- -E 1M -c 1 -S 1M -E 64M -c 1 -S 4M -E eof -c 4 -S 4M --ec 4+2.
When every raidset has one data stripe (--ec 1+N, or one data
stripe), there is one parity slot per data stripe and nothing to
pack, so rows and O count from file offset 0, as RAID0 does: ec_off
is the data offset, and each parity object is a copy of its data
object at the same object offsets, so it can stand in for it.
Otherwise O depends only on e_start, the data stripe count, k and the
stripe size, not on e_end, and when e_start is a multiple of the
stripe width, O is e_start.

Add ec_raidset_count(), ec_raidset_first(), ec_stripe_to_raidset()
and ec_off_to_raidset_offset() next to ec_split_stripes() in
lustre_user.h, and struct ec_parity_geom with ec_parity_geom_init(),
ec_data_to_parity() and its inverse ec_parity_to_data(), with
ec_parity_width() for the parity bytes of one stripe set, and use
them in lov, lod and llapi instead of open-coding the k0 * n0 split.
ec_parity_geom_init() also records the data row of parity slot 0 in
epg_row0 (0 for 1-data raidsets).
lov caches O in lsme_parity_origin when the layout is unpacked and
returns it from lsme_stripe_origin(), and lov_parity_geom_init()
fails a degraded read whose pair does not match in stripe size,
raidsets or origin; the parity mirror EOF of such a pair is also
bounded by one parity row per stripe set from e_start. Raidset
objects before e_start read as zero in degraded reads and resync.
A read is widened to whole raid sets, but not past the e_end of its
component, so a read ending there does not start an empty recovery
cycle for the next component's first raid set, which may begin before
its e_start.
lsme_parity_raid10() now just returns lsme_is_parity(), as every
parity component is LOV_PATTERN_PARITY, and
lsme_parity_slots_per_raidset() is dropped.

A component shorter than one stripe (e_end < e_start + stripe_size)
whose raidset continues past e_end (e.g. [64K, 1M) with -S 1M -c 2
--ec 2+2, or [1M, 4M) with -S 4M -c 2 --ec 2+2, where the second
stripe is never reached) still has no room for a full stripe_size
parity slot from e_start. ec_parity_fits() detects it:
llapi_layout_sanity() refuses it with LSE_EC_PARITY_FIT,
llapi_ec_check_comp_match() refuses to resync or verify it, and
lod_comp_prep_create() checks it again with the final data stripe
count, also for lfs mirror extend --ec.

The lov slot geometry, the STRIPE I/O scope and the per-stripe llapi
helpers were added by the previous patches and only take effect for
LOV_PATTERN_PARITY. This patch switches the encoding so they apply:
llapi_pattern_to_lov() and llapi_layout_to_lum() emit
LOV_PATTERN_PARITY, lov_pattern_supported() accepts it in place of
RAID0|PARITY (and lov_pattern_available() via that), and lod allocates
and verifies parity components with it. EC has not shipped, so the old
combination is not kept. Finite-extent stripe-count shrinking, now in
one lod_comp_shrink_to_extent() helper instead of three copies, is
skipped for parity components. lsm_unpackmd_comp_md_v1() and
lod_verify_striping() reject a component whose LCME_FL_PARITY flag and
LOV_PATTERN_PARITY disagree, since the parity geometry follows the
flag.

vvp_prep_size() no longer writes KMS into i_size for parity I/O.
ci_parity_eof is derived from i_size, and KMS is only a lower bound
of the data size, so a parity read within KMS shrank ci_parity_eof
for later parity I/O.

Userspace resync and verify move to the RAID10 offsets: one
stripe_size per raidset, each parity addressed by its stripe index,
leaving the part of the first parity slot below e_start alone. The
punch, zero-fill and hole verify of a parity slot are bounded by the
e_end of its component; no slot runs past e_end while
ec_parity_fits() holds, so this is only a defensive bound. Hole
punch-or-clear and hole verify loop over the p parity stripes that
share an offset when they fall back to zero-fill or zero-content
reads.

lfs setstripe --yaml parses the pattern as the comma-separated flags
lfs getstripe -y prints, so "parity,overstriped" keeps overstriping.

lfs mirror read of a parity mirror still dumps every parity object in
RAID0 order, through mirror_dump_parity() in lfs, from e_start.  The
dump of a component stops at its e_end: when the extent is not a
multiple of the data stripe set, the raid sets of the last row past
e_end hold the data of the next component.  The glimpse lock of such
a read spans every component, so lov_lock_sub_init() no longer
rejects a glimpse because a component the I/O does not cover has
fewer parity stripes than the designated one; lov_io_iter_init()
checks the components the I/O covers.

Example: -E 128M -c 11 -S 1M --ec 4+2

  data/parity extent [0, 128M)
  raidsets [4,2], [4,2], [3,2] (raidset_count=3)
  parity has 6 OST objects
  one data stripe set = 11M
  one parity stripe set = 3M (not 1M flat, not 6M concat)

  stripeset raidset data_pos    ec_off  concat  objects
  --------- ------- ----------- ------- ------- -------
  0         0       [0, 4M)     0       0       0,1
  0         1       [4M, 8M)    1M      2M      2,3
  0         2       [8M, 11M)   2M      4M      4,5
  1         0       [11M, 15M)  3M      6M      0,1
  1         1       [15M, 19M)  4M      8M      2,3
  1         2       [19M, 22M)  5M      10M     4,5

The concat column is what RAID0|PARITY would have used, and is what
overflows a finite extent when p > k.

Tests: sanity-ec 12c/12d/34c cover
holes and multi-raidset offsets, 30d and 31b-31e check the parity dump
size, 34d dumps a mixed-p mirror whose first extent is not a multiple
of the stripe set, 63d recovers reads from parity of raidset 1 in a
PFL component that does not start at 0, 301 covers an e_start that
stripe_size does not divide and checks that a component whose parity
would pass e_end is refused for that reason, 302 resyncs, verifies and
reads degraded common PFL layouts with an unaligned e_start, 303
recovers reads when e_start is not a multiple of the stripe width,
with equal and unequal raidsets, 304 covers zero-fill before e_start,
305 truncates at raidset and unaligned component boundaries, and 306
reads degraded across a component boundary where the raid set of the
first component runs into the next one.
llapi_layout_test asserts the component pattern is LLAPI_LAYOUT_PARITY
and 68 checks the parity placement over a range of geometries and
extents, and that 1-data raidset copies are at the data object
offsets.

Test-Parameters: testlist=sanity-ec ostcount=8
Test-Parameters: testlist=llapi_layout_test
Test-Parameters: testlist=sanity-ec ostcount=8 fstype=zfs
Signed-off-by: Keguang Xu <kxu@ddn.com>
Signed-off-by: Ronnie Sahlberg <rsahlberg@whamcloud.com>
Signed-off-by: Andreas Dilger <adilger@thelustrecollective.com>
Assisted-by: Cursor:Composer/Opus5.5 llm_code_and_review_tools
Assisted-by: ClaudeCode:claude-opus-5-5 ltvm llm_code_and_review_tools
Assisted-by: ClaudeCode:claude-fable-5-1 llm_code_and_review_tools
Change-Id: I9574df44969ddd40776f028b3c326d150ea08eb5

LU-20690 ec: verify parity against data, allow p > k

With the RAID10-like parity layout the p parities of a raidset share
one offset, so the parity of a component fits in its extent whatever
p is. Remove the p <= k checks in lfs and llapi; k+p <= 256 and
p <= 15 remain. Also drop the mirror-extend stripe_count < p guard
in ec_check_data_comp() so --ec 2+3 works on a two-stripe target.

An instantiated parity is checked against its data component in
lod_verify_ec_parity_comps() after lod_use_defined_striping() /
lod_parse_striping(), using lod_comp_find_linked() for the same
pairing rule as the allocator (covers layout-change replay). Require
a bidirectional link, matching k/p and stripe size, and parity stripe
count ec_raidset_count() * p. lod_verify_striping() checks k/p and
rejects an instantiated parity with stripe_count == 0 before
DEFINED object init.

Tests: sanity-ec 4a and 10 accept p > k, and 4b rejects k == 0 and
k > 255. 8m covers mirror extend --ec 2+3 on a two-stripe target.
300 covers PFL -E 2M --ec 2+3 create/resync/verify, and 305 covers
p > k multi-raidset create/resync/verify. llapi_layout_test test47
allows 3+4.

Test-Parameters: testlist=sanity-ec ostcount=8
Signed-off-by: Keguang Xu <kxu@ddn.com>
Assisted-by: Cursor:Composer llm_code_and_review_tools
Change-Id: I3878502e8ff739cb5ed420ff359e2008376303e7

LU-20690 ec: verify parity against data, allow p > k

With the RAID10-like parity layout the p parities of a raidset share
one offset, so the parity of a component fits in its extent whatever
p is. Remove the p <= k checks in lfs and llapi; k+p <= 256 and
p <= 15 remain. Also drop the mirror-extend stripe_count < p guard
in ec_check_data_comp() so --ec 2+3 works on a two-stripe target.

An instantiated parity is checked against its data component in
lod_verify_ec_parity_comps() after lod_use_defined_striping() /
lod_parse_striping(), using lod_comp_find_linked() for the same
pairing rule as the allocator (covers layout-change replay). Require
a bidirectional link, matching k/p and stripe size, and parity stripe
count ec_raidset_count() * p. lod_verify_striping() checks k/p and
rejects an instantiated parity with stripe_count == 0 before
DEFINED object init.

Tests: sanity-ec 4a and 10 accept p > k, and 4b rejects k == 0 and
k > 255. 8m covers mirror extend --ec 2+3 on a two-stripe target.
300 covers PFL -E 2M --ec 2+3 create/resync/verify, and 305 covers
p > k multi-raidset create/resync/verify. llapi_layout_test test47
allows 3+4.

Test-Parameters: testlist=sanity-ec ostcount=8
Signed-off-by: Keguang Xu <kxu@ddn.com>
Assisted-by: Cursor:Composer llm_code_and_review_tools
Change-Id: I3878502e8ff739cb5ed420ff359e2008376303e7

LU-20690 ec: store EC parity like RAID10

The k >= p restriction is not a Cauchy/ISA-L limit. It comes from
storing parity as RAID0|PARITY: the p parity objects of a raidset are
concatenated along the file offset, so raidset_count * p * stripe_size
does not fit in a finite PFL extent when p > k (for example
--ec 2+3 -E 2M). This patch changes the parity layout; the p <= k
checks in lfs and llapi stay until a following patch removes them.

Store EC parity as LOV_PATTERN_PARITY instead. A raidset is an EC
split of the stripe set, and the layout is like RAID10 in that it has
the same two axes:

  - across the raidsets of one stripe set: like RAID0, one
    stripe_size per raidset;
  - within one raidset: like RAID1, the p parity stripes share one
    file offset (the same object_off).

The RAID1 axis comes from recovery. A raidset of k data and p parity
stripes survives the loss of any p of its k + p stripes, just as a
RAID1 of p + 1 copies survives the loss of any p copies. RAID1 is the
k == 1 case, where each parity is a copy of the data (--ec 1+N). The
p parities protect the same data, so they share its offset: the
offset says which data is protected, the parity index says which
redundancy unit it is.

What differs from RAID1 is I/O, not the role. For k > 1 the parities
are not replicas: each holds a different parity, and a lost stripe is
rebuilt from any k survivors rather than copied from one. The parity
uses the extent of the data component.

RAID0 places data rows from file offset 0, whereas counting EC rows
and raidsets from e_start groups the wrong k stripes when e_start is
not a multiple of the data stripe width: the stripes EC groups as one
raidset are not the objects lod paired with that raidset's parity
OSTs, and a degraded read rebuilds a lost stripe from the wrong
parity. For example -E 4M -c 1 -E eof -S 1M -c 8 --ec 4+1 puts offset
4M on object 4 (raidset 1), which counting from e_start encodes into
the parity of raidset 0. When e_start is not a multiple of
stripe_size, as after a 64K DoM component, counting stripe_size
parity slots from e_start also splits stripes at
e_start + n * stripe_size and overflows e_end.

Count rows and raidsets from file offset 0, as RAID0 maps the data
objects:

  row = off / (stripe_count * stripe_size)
  ec_off = O
      + (row - row of e_start) * raidset_count * stripe_size
      + raidset * stripe_size + off % stripe_size

Data before e_start is taken as zero, and so is its parity, which is
not stored: the origin O moves back from e_start over the raidsets of
the first row that end before e_start, and over the part of the
raidset of e_start below e_start % stripe_size when e_start is in its
last data stripe. slot % raidset_count stays the raidset, so the
parity OSTs lod pairs are unchanged, and every stored parity byte has
data in the component. Common DoM and PFL layouts with an unaligned
e_start are supported and keep their parity within [e_start, e_end),
such as:
- -E 64K -L mdt -E 1M -c 1 -S 1M -E eof -c 4 -S 4M --ec 4+2;
- -E 64K -L mdt -E 16M -c 2 -S 1M -E eof -c 4 -S 4M --ec 2+2;
- -E 64K -L mdt -E eof -c 4 -S 1M --ec 2+2;
- -E 1M -c 1 -S 1M -E 64M -c 1 -S 4M -E eof -c 4 -S 4M --ec 4+2.
When every raidset has one data stripe (--ec 1+N, or one data
stripe), there is one parity slot per data stripe and nothing to
pack, so rows and O count from file offset 0, as RAID0 does: ec_off
is the data offset, and each parity object is a copy of its data
object at the same object offsets, so it can stand in for it.
Otherwise O depends only on e_start, the data stripe count, k and the
stripe size, not on e_end, and when e_start is a multiple of the
stripe width, O is e_start.

Add ec_raidset_count(), ec_raidset_first(), ec_stripe_to_raidset()
and ec_off_to_raidset_offset() next to ec_split_stripes() in
lustre_user.h, and struct ec_parity_geom with ec_parity_geom_init(),
ec_data_to_parity() and its inverse ec_parity_to_data(), with
ec_parity_width() for the parity bytes of one stripe set, and use
them in lov, lod and llapi instead of open-coding the k0 * n0 split.
ec_parity_geom_init() also records the data row of parity slot 0 in
epg_row0 (0 for 1-data raidsets).
lov caches O in lsme_parity_origin when the layout is unpacked and
returns it from lsme_stripe_origin(), and lov_parity_geom_init()
fails a degraded read whose pair does not match in stripe size,
raidsets or origin; the parity mirror EOF of such a pair is also
bounded by one parity row per stripe set from e_start. Raidset
objects before e_start read as zero in degraded reads and resync.
A read is widened to whole raid sets, but not past the e_end of its
component, so a read ending there does not start an empty recovery
cycle for the next component's first raid set, which may begin before
its e_start.
lsme_parity_raid10() now just returns lsme_is_parity(), as every
parity component is LOV_PATTERN_PARITY, and
lsme_parity_slots_per_raidset() is dropped.

A component shorter than one stripe (e_end < e_start + stripe_size)
whose raidset continues past e_end (e.g. [64K, 1M) with -S 1M -c 2
--ec 2+2, or [1M, 4M) with -S 4M -c 2 --ec 2+2, where the second
stripe is never reached) still has no room for a full stripe_size
parity slot from e_start. ec_parity_fits() detects it:
llapi_layout_sanity() refuses it with LSE_EC_PARITY_FIT,
llapi_ec_check_comp_match() refuses to resync or verify it, and
lod_comp_prep_create() checks it again with the final data stripe
count, also for lfs mirror extend --ec.

The lov slot geometry, the STRIPE I/O scope and the per-stripe llapi
helpers were added by the previous patches and only take effect for
LOV_PATTERN_PARITY. This patch switches the encoding so they apply:
llapi_pattern_to_lov() and llapi_layout_to_lum() emit
LOV_PATTERN_PARITY, lov_pattern_supported() accepts it in place of
RAID0|PARITY (and lov_pattern_available() via that), and lod allocates
and verifies parity components with it. EC has not shipped, so the old
combination is not kept. Finite-extent stripe-count shrinking, now in
one lod_comp_shrink_to_extent() helper instead of three copies, is
skipped for parity components. lsm_unpackmd_comp_md_v1() and
lod_verify_striping() reject a component whose LCME_FL_PARITY flag and
LOV_PATTERN_PARITY disagree, since the parity geometry follows the
flag.

vvp_prep_size() no longer writes KMS into i_size for parity I/O.
ci_parity_eof is derived from i_size, and KMS is only a lower bound
of the data size, so a parity read within KMS shrank ci_parity_eof
for later parity I/O.

Userspace resync and verify move to the RAID10 offsets: one
stripe_size per raidset, each parity addressed by its stripe index,
leaving the part of the first parity slot below e_start alone. The
punch, zero-fill and hole verify of a parity slot are bounded by the
e_end of its component; no slot runs past e_end while
ec_parity_fits() holds, so this is only a defensive bound. Hole
punch-or-clear and hole verify loop over the p parity stripes that
share an offset when they fall back to zero-fill or zero-content
reads.

lfs setstripe --yaml parses the pattern as the comma-separated flags
lfs getstripe -y prints, so "parity,overstriped" keeps overstriping.

lfs mirror read of a parity mirror still dumps every parity object in
RAID0 order, through mirror_dump_parity() in lfs, from e_start.  The
dump of a component stops at its e_end: when the extent is not a
multiple of the data stripe set, the raid sets of the last row past
e_end hold the data of the next component.  The glimpse lock of such
a read spans every component, so lov_lock_sub_init() no longer
rejects a glimpse because a component the I/O does not cover has
fewer parity stripes than the designated one; lov_io_iter_init()
checks the components the I/O covers.

Example: -E 128M -c 11 -S 1M --ec 4+2

  data/parity extent [0, 128M)
  raidsets [4,2], [4,2], [3,2] (raidset_count=3)
  parity has 6 OST objects
  one data stripe set = 11M
  one parity stripe set = 3M (not 1M flat, not 6M concat)

  stripeset raidset data_pos    ec_off  concat  objects
  --------- ------- ----------- ------- ------- -------
  0         0       [0, 4M)     0       0       0,1
  0         1       [4M, 8M)    1M      2M      2,3
  0         2       [8M, 11M)   2M      4M      4,5
  1         0       [11M, 15M)  3M      6M      0,1
  1         1       [15M, 19M)  4M      8M      2,3
  1         2       [19M, 22M)  5M      10M     4,5

The concat column is what RAID0|PARITY would have used, and is what
overflows a finite extent when p > k.

Tests: sanity-ec 12c/12d/34c cover
holes and multi-raidset offsets, 30d and 31b-31e check the parity dump
size, 34d dumps a mixed-p mirror whose first extent is not a multiple
of the stripe set, 63d recovers reads from parity of raidset 1 in a
PFL component that does not start at 0, 301 covers an e_start that
stripe_size does not divide and checks that a component whose parity
would pass e_end is refused for that reason, 302 resyncs, verifies and
reads degraded common PFL layouts with an unaligned e_start, 303
recovers reads when e_start is not a multiple of the stripe width,
with equal and unequal raidsets, 304 covers zero-fill before e_start,
305 truncates at raidset and unaligned component boundaries, and 306
reads degraded across a component boundary where the raid set of the
first component runs into the next one.
llapi_layout_test asserts the component pattern is LLAPI_LAYOUT_PARITY
and 68 checks the parity placement over a range of geometries and
extents, and that 1-data raidset copies are at the data object
offsets.

Test-Parameters: testlist=sanity-ec ostcount=8
Test-Parameters: testlist=llapi_layout_test
Test-Parameters: testlist=sanity-ec ostcount=8 fstype=zfs
Signed-off-by: Keguang Xu <kxu@ddn.com>
Signed-off-by: Ronnie Sahlberg <rsahlberg@whamcloud.com>
Signed-off-by: Andreas Dilger <adilger@thelustrecollective.com>
Assisted-by: Cursor:Composer/Opus5.5 llm_code_and_review_tools
Assisted-by: ClaudeCode:claude-opus-5-5 ltvm llm_code_and_review_tools
Assisted-by: ClaudeCode:claude-fable-5-1 llm_code_and_review_tools
Change-Id: I9574df44969ddd40776f028b3c326d150ea08eb5