lfsck_layout_slave_repair_pfid() calls __lfsck_layout_update_pfid() with its last three arguments out of order:

static int __lfsck_layout_update_pfid(const struct lu_env *env,
				      struct lfsck_component *com,
				      struct dt_object *child,
				      const struct lu_fid *pfid,
				      const struct ost_layout *ol, __u32 offset,
				      __u32 version, __u32 range)
...
	rc = __lfsck_layout_update_pfid(env, com, obj,
					&lrl->lrl_ff_client.ff_parent,
					&lrl->lrl_ff_client.ff_layout,
					lrl->lrl_ff_client.ff_layout_version,
					lrl->lrl_ff_client.ff_range,
					lrl->lrl_ff_client.ff_parent.f_ver);

The layout version is passed as the stripe index (offset), the range as the layout version, and the stripe index (ff_parent.f_ver) as the range.

This came in with 36ba989752c ("LU-10288 lfsck: layout LFSCK for mirrored file"), which added the version and range parameters after offset but inserted the new arguments ahead of f_ver at this caller. The other callers pass them in order.

This is the OST-side PFID repair: when the OST finds that a client's PFID for an object differs from the one stored and the MDT confirms the client's is right, the OST rewrites the object's filter_fid from lrl_ff_client. ofd_add_inconsistency_item() leaves ff_layout_version and ff_range zero there, so the rewritten filter_fid gets stripe index 0, layout version 0 and a range equal to the real stripe index. For any stripe other than 0, the "repaired" object then names the wrong stripe index, which a later layout LFSCK reports as an unmatched pair, and orphan recovery would put it in the wrong slot.

Fix: pass ff_parent.f_ver as offset, then ff_layout_version and ff_range.

Found during review of https://review.whamcloud.com/62389 (LU-19566), which extends the same call.