# Promises — change 64620: LU-19548 lfs: update mirror split for EC support
Branch master · PS23 · MERGED · https://review.whamcloud.com/c/fs/lustre-release/+/64620
Harvested 2026-11-05
Checked at PS23 (2e591389646c), master 550451c0e4b9
Refer to items by id, e.g. "address item 64620-6d081ddf".

## Open (6)

### 64620-6d081ddf — lustre/utils/lfs.c:6287 [severity: high]
*The thread is marked resolved, but the item is still open.*
**Summary:** Free and re-fetch layout per file in multi-file mirror split/delete so resync decisions use the correct file's layout
**Origin:** comment on PS20, thread resolved; promise by Marc Vef: "this should be addressed but in a separate patch."
**Thread:**
> [Gerrit AI review for Lustre, 2026-08-29] (defect) `layout` is a function-scope variable that is only freed and reset inside this loop under `restripe` and in the auto-stripe migrate branch, neither of which applies to SO_MIRROR_SPLIT/SO_MIRROR_DELETE. So on a multi-file command it is fetched from the first file and reused for every later one, and the resync decision for file 2..N is made against file 1's layout.
> 
> This predates the patch, but the new `data_mirror_remains()` call is a second consumer of it, and sanity-flr test_44f added here splits 40 files in one command, so the path is now routinely exercised.
> 
> Concretely, if file1 has two healthy data mirrors then `last_non_stale_mirror()` returns false and the resync is skipped for file2 as well, even when the mirror being split is file2's only non-stale copy. Should the layout be freed and re-fetched per file here?
> [Marc Vef, 2026-08-31] this was raised before. This should be addressed but in a separate patch. The issue predates this patch and was introduced by 81481104fdc ("LU-13720 lfs: resync file if needed before mirror_split()", Dec 2024.
**Code context:**
```
    6282: 			 * that split, and resyncing first would recompute
    6283: 			 * parity over the whole file only for it to fail.
    6284: 			 */
    6285: 			result = 0;
    6286: 			if (!layout)
>>> 6287: 				layout = layout_get_by_name_or_fid(template ?:
    6288: 						fname, fname, 0, O_RDONLY);
    6289: 			if (data_mirror_remains(layout, mirror_id) &&
    6290: 			    last_non_stale_mirror(mirror_id, layout)) {
    6291: 				struct ll_ioc_lease *ioc = NULL;
    6292: 
```
**Check (AI, 2026-09-28, verdict still-open):** On master (550451c0e4b9), master/lustre/utils/lfs.c:6384-6388 still only fetches the layout when it is NULL ('if (!layout) layout = layout_get_by_name_or_fid(...)'), then feeds it to data_mirror_remains() and last_non_stale_mirror() for SO_MIRROR_SPLIT/SO_MIRROR_DELETE. Inside the per-file loop, the layout is only freed and reset under restripe (lfs.c:6246-6248) and in the auto-stripe migrate branch (lfs.c:6320-6321). So in a multi-file split or delete, files 2..N are still judged against file 1's layout. None of the candidate diffs (58229, 68697, 68696, 65921, 66672, 66113, 68278) touch last_non_stale_mirror or this layout fetch. Marc Vef deferred the fix to a separate patch, and I can't find that patch anywhere here.
**Suggested action:** In lfs_setstripe_internal's per-file loop, for SO_MIRROR_SPLIT/SO_MIRROR_DELETE (when no template is given), free the layout and fetch it again for each fname before calling data_mirror_remains()/last_non_stale_mirror(). Add a sanity-flr test that splits several files in one command, where only a later file needs the resync.
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/6d081ddf_64810ce4/

### 64620-4fd76819 — lustre/utils/lfs.c:6289 [severity: high]
*The thread is marked resolved, but the item is still open.*
**Summary:** Resolve mirror id once for -I/--pool paths so collect_mirror_id() doesn't wrongly count the mirror being split as a surviving copy
**Origin:** comment on PS20, thread resolved; promise by Marc Vef: "the `-p` issue is correct but predates this patch and will be addressed in a follow-up"
**Thread:**
> [Gerrit AI review for Lustre, 2026-08-29] (defect) `mirror_id` here is still 0 unless `--mirror-id` was given: the branch just above sets `comp_id` or `MF_COMP_POOL` for `-I` and `--pool` and leaves `mirror_id` alone. Both helpers then run with `cid_exclude == 0`, and no mirror has id 0, so `collect_mirror_id()` also collects the mirror that is about to be split and counts it as a surviving good copy.
> 
> Take {D1 in-sync EC data, P1 its parity, D2 stale} and
> 
>     lfs mirror delete --pool ssd FILE   (or -I <D1 comp id>)
> 
> `last_non_stale_mirror(0, layout)` finds D1 non-stale, returns false, and the resync is skipped. mirror_split() then resolves the mirror itself, co-splits D1+P1, and the file is left with only stale D2 - the same loss the `--mirror-id` path is being fixed for.
> 
> Could the mirror id be resolved once (as mirror_split() does with find_comp_id/find_mirror_id_by_pool) and passed to both helpers?
> [Marc Vef, 2026-08-31] this comment was raised before. (1) -d is mutually exclusive with -I and refused on arg parsing. (2) the `-p` issue is correct but predates this patch and will be addressed in a follow-up
**Code context:**
```
    6284: 			 */
    6285: 			result = 0;
    6286: 			if (!layout)
    6287: 				layout = layout_get_by_name_or_fid(template ?:
    6288: 						fname, fname, 0, O_RDONLY);
>>> 6289: 			if (data_mirror_remains(layout, mirror_id) &&
    6290: 			    last_non_stale_mirror(mirror_id, layout)) {
    6291: 				struct ll_ioc_lease *ioc = NULL;
    6292: 
    6293: 				ioc = calloc(1, sizeof(*ioc) +
    6294: 						sizeof(__u32) * IOC_IDS_MAX);
```
**Check (AI, 2026-09-28, verdict still-open):** The follow-up Marc Vef promised has not been done anywhere I can see. On master (master/lustre/utils/lfs.c:6364-6369), the split/delete branch only sets MF_COMP_POOL, or MF_COMP_ID, or copies mirror_id into comp_id. It never works out mirror_id for the -I or --pool paths. So at lines 6387-6388, data_mirror_remains(layout, mirror_id) and last_non_stale_mirror(mirror_id, layout) are still called with mirror_id == 0 unless --mirror-id was given. That means the mirror being split can still be counted as a surviving good copy. The current patchset has the same code (change/lustre/utils/lfs.c:6385-6386). The history files contain only this change's own commit, which adds data_mirror_remains and still passes the raw mirror_id. A search of the candidate diffs for last_non_stale_mirror, data_mirror_remains and find_mirror_id_by_pool found nothing. None of the NEW follow-ups (58229, 68697, 68696, 65921, 66672) or the MERGED ones (66113, 68278) touch this code. The reviewer's point holds: the author agreed the --pool case is a real bug and did not withdraw it. The author also said -d cannot be combined with -I, but the resync check still runs with mirror_id 0 for plain -I splits, so that does not settle it.
**Suggested action:** In the SO_MIRROR_SPLIT/SO_MIRROR_DELETE branch of lfs_setstripe_internal(), when mirror_id is 0, work out the target mirror id before the resync check, the same way mirror_split() does. Use find_comp_id plus mirror_id_of for -I, and find_mirror_id_by_pool for --pool. Pass that resolved id to both data_mirror_remains() and last_non_stale_mirror(). Add a sanity-ec test: take a file with an in-sync EC data mirror plus parity and a stale mirror, delete it with --pool and with -I, and check that the file keeps a non-stale data copy.
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/4fd76819_296cf349/

### 64620-5e9e1c38 — Documentation/man1/lfs-mirror-split.1:85 [severity: med]
*The thread is marked resolved, but the item is still open.*
**Summary:** Support merging data+parity split victim in mirror extend follow-up patch
**Origin:** comment on PS15, thread resolved; promise by Maximilian Dilger: "as said, will be fixed in a follow up patch."
**Thread:**
> [Gerrit AI review for Lustre, 2026-08-18] (minor) The victim now gets two mirrors, and lod_declare_layout_merge() rejects any merge source that has more than one:
> 
>     if (le16_to_cpu(merge_lcm->lcm_mirror_count))
>         RETURN(-EBUSY);
> 
> So `lfs mirror extend -N -f NEW_FILE` (documented in lfs-mirror-extend.1) fails with EBUSY on a file produced this way, unlike every other split victim. Should this paragraph say so, until extend learns to merge a data+parity pair?
> [Andreas Dilger, 2026-08-20] Updating the man page to explain this would be useful, but I don't think re-merging a data mirror+parity into an existing file is a necessary operation.  Since the mirror+EC would need to be resync'd anyway, it is not more efficient than just creating a new mirror on the target file and resyncing that, or merging a plain data mirror and then adding another EC.
> [Marc Vef, 2026-08-20] This is fine and will be addressed in the follow-up patch.
> [Marc Vef, 2026-08-20] Looks like we commented at the same time. This is a good point and would simplify things for mirror extend. Since we need to resync anyway, it would be enough to add an EC mirror to the extended data mirror. This way, the same `--ec` configuration is automatically used on the target file. I guess this could be done from user space, we don't need to modify the merge layout functionality on the mds. I'll reflect on that further later
> [Maximilian Dilger, 2026-08-21] as said, will be fixed in a follow up patch.
> [Andreas Dilger, 2026-08-22] To clarify, does that mean functionality added in this patch would be removed in a later patch?  That is bad form, as it makes the code and history more complex, and often leaves cruft behind (or is never removed).  Better to not add the unnecessary functionality in the first place.
> [Maximilian Dilger, 2026-08-24] no, none of what's being added by this patch should need to be removed later. this patch is still being followed by the mirror extend patch and i think the comment left by the bot originally isn't taking that into account.
**Code context:**
```
      80: .BI -f " NEW_FILE"
      81: This option indicates the layout of the split mirror will be stored into
      82: .IR NEW_FILE .
      83: If the split mirror is an EC data mirror, both the data and its associated
      84: parity mirror will be moved to
>>>   85: .IR NEW_FILE .
      86: .P
      87: This option cannot be used on encrypted files when the encryption key is not
      88: available. It will result in
      89: .BR -ENOKEY .
      90: .SH EXAMPLES
```
**Check (AI, 2026-09-28, verdict still-open):** Nothing I can see has done the promised work. The merge check that rejects any source file with mirrors is still there on master (master/lustre/lod/lod_object.c:3435-3437 in lod_declare_layout_merge(): `if (le16_to_cpu(merge_lcm->lcm_mirror_count)) RETURN(-EBUSY)`). So after `lfs mirror split -f` moves a data mirror and its parity mirror into NEW_FILE, `lfs mirror extend -f NEW_FILE` still fails with EBUSY. The man page doesn't mention this either: master/Documentation/man1/lfs-mirror-split.1:97-108 says the data+parity pair is moved to NEW_FILE and that splitting a parity mirror alone is refused, but says nothing about EBUSY on a later extend. The 'mirror extend patch' Maximilian pointed to is change 65921, which is still NEW. It adds only `--ec`, `--mirror-id` and auto-attach of parity. It refuses `--ec` together with `-f` (candidates/65921.diff:204-208 and 2312-2320). Its lod_object.c hunk (lines 506-571) only links merged parity components to their data mirror and leaves the mirror_count EBUSY check alone. 58229 (no match for lcm_mirror_count or EBUSY in its diff) and 68697 (refuses to split a parity mirror into its own file) don't cover it either. Andreas argued that re-merging a data+parity pair isn't needed, since a resync is required anyway, so the merge itself can reasonably be dropped. But he said the man page note 'would be useful', and that note was never added.
**Suggested action:** In lfs-mirror-split.1 (-f NEW_FILE) and lfs-mirror-extend.1 (-f), state that a NEW_FILE holding an EC data+parity pair cannot be merged back with 'lfs mirror extend -f' (it fails with EBUSY). Tell users to merge a plain data mirror instead and then add parity with 'lfs mirror extend --ec'. Optionally, have lfs detect a mirrored victim and print a clear error before the MDS returns EBUSY.
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/5e9e1c38_a5aef047/

### 64620-f152f03c — COMMIT_MSG:28 [severity: low]
**Summary:** Document --no-warn option in commit message if refreshed
**Origin:** comment on PS22; promise by Gerrit AI review for Lustre: "If the patch is refreshed, a sentence in the second paragraph would cover it."
**Thread:**
> [Gerrit AI review for Lustre, 2026-09-09] (minor) The body doesn't mention the new `--no-warn` option or the warning it suppresses, yet both are new user-visible behaviour: `lfs mirror split` and `lfs mirror delete` gain the option, a warning is now printed by default when a parity destroy takes away the last redundant copy, and two man pages are updated for it. The house rule is that the message should name the new command/parameter so it is findable via `git log` grep later.
> 
> If the patch is refreshed, a sentence in the second paragraph would cover it.
**Check (AI, 2026-09-28, verdict still-open):** The promise was to mention the option if the patch was refreshed. It was refreshed from PS22 to PS23, and PS23 merged as commit 2e591389646c. Its commit message (history/f152f03c_0ad701c1.txt:264-303) covers the parity pair split/destroy, the split refusals, the resync fixes and the endian bugs, but never mentions `--no-warn` or the new default warning when destroying parity removes the last redundant copy. The option itself did land in that commit: the lfs-mirror-delete/split man pages (history:320-462) and lfs.c (history:1362-1371, 1782, 1827). No follow-up in candidates/ mentions `--no-warn` (grep found nothing), including 66113, which merged afterwards as c8fe1ced8f20. So a `git log --grep=no-warn` search still finds nothing, which is the gap the comment pointed at. The commit message of a merged change can't be amended now.
**Suggested action:** The merged commit message can't be changed, so name `--no-warn` for `lfs mirror split`/`lfs mirror delete`, and the default warning when a parity destroy removes the last redundant copy, in the commit message of the next related LU-19548 follow-up (e.g. 65921 or 68697), so it can be found with `git log --grep`. Otherwise close the item as not fixable for 64620.
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/f152f03c_0ad701c1/

### 64620-3a10ec1d — Documentation/man1/lfs-mirror-split.1:14 [severity: low]
**Summary:** Update man page synopsis to show -d/-f as mutually exclusive
**Origin:** comment on PS22
**Thread:**
> [Gerrit AI review for Lustre, 2026-09-09] (minor) The synopsis shows `[--destroy|-d]` and `[-f NEW_FILE]` as independently optional, but this patch makes them mutually exclusive in both orders - `case 'f'` now rejects `-f` once MF_DESTROY is set, and `case 'd'` already rejected `-d` after `-f`. Worth folding them into one alternation, and saying so in the OPTIONS text for `-d`, so the page matches what the parser accepts.
**Code context:**
```
       9: .BR --component-id | --comp-id | -I
      10: .I COMP_ID
      11: |
      12: .B --pool
      13: .IR POOL }
>>>   14: .RB [ --destroy | -d ]
      15: .RB [ --no-warn ]
      16: .RB [ -f
      17: .IR NEW_FILE ]
      18: .I MIRRORED_FILE
      19: .YS
```
**Check (AI, 2026-09-28, verdict still-open):** The comment is correct. On master (550451c0e4b9, which contains the merged commit 2e591389646c), lustre/utils/lfs.c rejects the two options in both orders: about line 5139 prints "-d cannot be used with -f" and line 5280 prints "-f cannot be used with -d". But master/Documentation/man1/lfs-mirror-split.1:14-17 still lists .RB [ --destroy | -d ] and .RB [ -f NEW_FILE ] as separate optional items. The -d text in OPTIONS (lines 86-91) and the -f text (lines 97-113) don't say the two can't be combined either. The history file only has 2e591389646c, which added --no-warn but didn't touch this. No candidate diff changes lfs-mirror-split.1, and the replies don't withdraw the item.
**Suggested action:** In Documentation/man1/lfs-mirror-split.1, merge the separate [--destroy|-d] and [-f NEW_FILE] synopsis entries into one alternation, e.g. .RB [ --destroy | -d | -f .IR NEW_FILE ]. Also add a sentence to both the -d and -f OPTIONS entries saying they are mutually exclusive.
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/3a10ec1d_48c116cf/

### 64620-0c53ebe8 — lustre/lod/lod_object.c:3759 [severity: low]
*The thread is marked resolved, but the item is still open.*
**Summary:** Decide whether multi-mirror split should iterate instead of erroring, possibly in follow-on patch
**Origin:** comment on PS18, thread resolved
**Thread:**
> [wc-checkpatch, 2026-08-25] (style)  Review error messages to ensure they are useful, and not just status/debug
> 
> [Andreas Dilger, 2026-08-25] Do you think this is a usage error if the user requests splitting multiple mirrors, or just a limitation in the current implementation?
> 
> IMHO it would be more convenient for the user to just iterate over all the mirrors one-at-a-time (possibly by `lfs` on the client rather than on the server) instead of returning an error, especially in the case of -N=2 or similar removing multiple mirrors that were added to a file for caching or by accident.  That could be done in a follow-on patch, to avoid delaying this one.
**Code context:**
```
    3754: 	/* from now on, @buf contains cpu endian data */
    3755: 
    3756: 	/* Allow purging a single mirror, or a data + parity mirror pair */
    3757: 	if (comp_v1->lcm_mirror_count > 1) {
    3758: 		rc = -EINVAL;
>>> 3759: 		CERROR("%s: cannot purge %u mirrors at once from "DFID": rc = %d\n",
    3760: 		       lod2obd(d)->obd_name, comp_v1->lcm_mirror_count + 1,
    3761: 		       PFID(lu_object_fid(&dt->do_lu)), rc);
    3762: 		RETURN(rc);
    3763: 	}
    3764: 
```
**Check (AI, 2026-09-28, verdict still-open):** Split still rejects requests for more than one mirror. The check `if (comp_v1->lcm_mirror_count > 1)` with CERROR "cannot purge %u mirrors at once" and -EINVAL is unchanged at master/lustre/lod/lod_object.c:3757-3762 and at the same lines in change/ PS23. On the client, lfs mirror_split() (master/lustre/utils/lfs.c:2752, called at :6406) still takes a single mirror id and does not loop over several mirrors. None of the candidate diffs change this check or add iteration; a grep for lcm_mirror_count, mirror_split and 'cannot purge' finds nothing relevant. Only 65921.diff:577 matches lcm_mirror_count, and that line is unrelated mirror-extend code. Andreas deferred this to a follow-on patch, and no such patch is visible. Marking the thread resolved did not implement it.
**Suggested action:** In lfs mirror split, when the user asks to split several mirrors (e.g. -N 2 or several mirror ids), loop and split them one at a time instead of failing with -EINVAL. Also decide whether the lod_object.c check is a usage error or just a current implementation limit, and make the CERROR message say which.
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/0c53ebe8_ed7334f2/


## In flight (1)

### 64620-a08dac95 — lustre/mdd/mdd_object.c:2042 [severity: med]
**Summary:** Enforce on MDS that a parity-only victim file cannot be created
**Origin:** comment on PS19, thread resolved; promise by Marc Vef: "Addressed in https://review.whamcloud.com/c/fs/lustre-release/+/68697"
**Thread:**
> [Gerrit AI review for Lustre, 2026-08-28] (minor) Keeping LCME_FL_PARITY on the victim entries means a direct parity split now hands a victim file whose only component is parity. Nothing on the MDS refuses that - data_remains only protects the source - so the "a file containing only a parity mirror cannot be read" rule documented in lfs-mirror-split.1 lives solely in mirror_split(), and any other client (or an unpatched lfs) can still create such a file. mdd_xattr_split() already knows whether a victim object exists (mrd->mrd_obj), so this could be enforced here too. Was that deliberate?
> [Marc Vef, 2026-08-31] Agreed. For belt and suspenders, this should be added on the MDS side (`mrd_obj != NULL`). Reasonable if the patch is refreshed, in a follow-up otherwise.
> [Marc Vef, 2026-09-07] Done
> [Marc Vef, 2026-09-07] Reopening this. This warants another patch because it depends on another unrelated bug on master I need to investigate. I will push a separate patch
> [Marc Vef, 2026-09-07] Addressed in https://review.whamcloud.com/c/fs/lustre-release/+/68697
**Code context:**
```
    2037: 			vic = true;
    2038: 
    2039: 		/* copy component entry */
    2040: 		if (vic) {
    2041: 			memcpy(entry_vic, entry, sizeof(*entry));
>>> 2042: 			entry_vic->lcme_flags &= cpu_to_le32(vic_flag_mask);
    2043: 			if (vic_parity_stale && parity_id && mid == parity_id)
    2044: 				entry_vic->lcme_flags |=
    2045: 					cpu_to_le32(LCME_FL_STALE);
    2046: 			entry_vic->lcme_offset = cpu_to_le32(offset_vic);
    2047: 			/* If the paired mirror stays behind (a direct parity
```
**Check (AI, 2026-09-28, verdict in-followup):** Master (550451c0e4b9) still has no MDS check. In master/lustre/mdd/mdd_object.c, target_is_parity is set around lines 1910-1945, but it only feeds the link_id pairing logic. It never causes a victim split of a parity mirror to be refused, and the only uses of mrd_obj (lines 2127 and 2327) pick the victim object. candidates/68697.diff adds a has_victim && target_is_parity check to mdd_split_ea() that logs CERROR 'cannot split parity mirror ... into a file of its own' and returns -EINVAL. It also changes lfs.c so lfs no longer takes the old-MDS volatile fallback for a parity target. 68697 is still NEW, so this is not landed yet.
**Suggested action:** Land 68697. Add a sanity-ec test that asks the MDS directly (without lfs's client-side check) to split a parity mirror into a victim file, and check that it fails with -EINVAL.
**In flight:** change 68697 (NEW): LU-19548 mdd: refuse to split a parity mirror to a victim
**Possible follow-ups:** 68697 (NEW, linked in the thread)
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/a08dac95_b61396c6/


## To check (2)

### 64620-da097ab4 — (change-level) [severity: low]
*Status: unclear.*
**Summary:** File small follow-up patch for remaining issue
**Origin:** comment on PS20, thread resolved; promise by Keguang Xu: "Maybe another small patch to fix it?"
**Thread:**
> [Keguang Xu, 2026-09-02] @mvef@whamcloud.com, approve +1, but still one issue left. Maybe another small patch to fix it?
> [Marc Vef, 2026-09-02] Agreed, many thanks Keguang.
**Check (AI, 2026-09-28, verdict unclear):** Keguang Xu's PS20 comment only says "still one issue left" and never names it. No code context was captured, and Marc Vef's reply ("Agreed") does not name it either. The change merged as 2e591389646c. The only later master commit touching these files is c8fe1ced8f20 (66113, `lfs getstripe --ec-map`), which adds new output and does not fix anything in mirror split. Two open follow-ups from Marc Vef touch this code: 68697 enforces in the MDS (mdd_split_ea() with has_victim) the rule that a lone parity mirror cannot be split into a file of its own. 68696 declares the layout split before the purge in mdd_xattr_split(), which stops the -EINVAL fallback to a volatile file. Either could be the issue Keguang meant, but nothing here ties either one to his comment. Merged 68278 only changes the OST count in sanity-ec test_7d.
**Suggested action:** Ask Keguang Xu which issue he meant on PS20 of change 64620. Then check whether open changes 68697 or 68696 fix it, or file a small LU-19548 follow-up if neither does.
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/da097ab4_939614f5/

### 64620-80d744ff — (change-level) [severity: low]
*Status: unclear.*
**Summary:** Fix minor link-id handling issues in follow-up patch
**Origin:** comment on PS19, thread resolved; promise by Marc Vef: "There are a few minor issues that are worthwhile to fix if refreshed or otherwise in a follow-up."
**Thread:**
> [Marc Vef, 2026-08-27] The patch and the link id handling look correct. There are a few minor issues that are worthwhile to fix if refreshed or otherwise in a follow-up. In any case, I put them on my list so we don't forget later
**Check (AI, 2026-09-28, verdict unclear):** The PS19 change-level comment says only that there are 'a few minor issues' with link-id handling. It does not list them; they were probably in inline comments that were not captured. The link-id code merged in 2e591389646c adds mdd_lcme_link_id, mdd_ec_pair_linked and mdd_lcme_clear_link_id, plus parity_mirror_link in lfs (history/80d744ff_f21809c1.txt:503-782, 1396-1765). Since then, master has only c8fe1ced8f20 (LU-20036 --ec-map), which reads lcme_mirror_link_id but does not change split handling. Among the NEW candidates, 68697 (refuse to split a parity mirror to a victim) and 68696 are in this area, but I can't match either one to issues that were never named.
**Suggested action:** Get Marc Vef's list of minor link-id issues from PS19 (inline comments or his notes). Check each one against master 2e591389646c and candidates 68697 and 68696, then fix whatever is still open in a follow-up.
**Gerrit:** https://review.whamcloud.com/c/fs/lustre-release/+/64620/comment/80d744ff_f21809c1/


## Kept (2)

- **64620-bd8c919f** (change-level) — Fix resync-stale-mirror-before-delete-last-copy before final release (kept in patchset 23 — The resync step now runs only when data_mirror_remains() is true, so a stale mirror is no longer resynced before a split that will be refused.)
- **64620-b0c0df4a** lustre/tests/sanity-ec.sh:2203 — Add a -q option to quiet the parity-split warning (kept in patchset 23 — A --no-warn option (not -q) was added to lfs mirror split and lfs mirror delete. It sets MF_NO_WARN, which turns off the parity-mirror redundancy warning.)

## Set aside (2)

- **64620-0dd5bb1a** COMMIT_MSG:28 — Document new -f/-d usage-error interaction in commit message (judged not needed)
- **64620-1f2910f6** Documentation/man1/lfs-mirror-delete.1:64 — Add --force-no-ec functionality back in future patch if needed (judged not needed)