LU-19548 lfs: update mirror split for EC support

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. Copy as prompt

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. Copy as prompt

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. Copy as prompt

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. Copy as prompt

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. Copy as prompt

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. Copy as prompt