zstream should be able to rechunk records.

[rincebrain]

Describe the feature would like to see added to OpenZFS

Similar to #16183, but instead of en/decrypting, I think we already understand the edge cases involved in doing something like zfs send -RLec mypool/ds1_128k@snap4 | zstream resize -o recordsize=4M | ....

Obviously you're not going to get away with this on something that's encrypted when it comes in, but I think at most you need a new partial write verb for send streams, or just handling in receive directly, to be able to say "I know this is a 4M record in your head, but please go rewrite this 128k region", since IIRC right now the verbs you have in send streams are just "delete" and "write entire record".

How will this feature improve OpenZFS?

A lot of time has been spent, at least by me, on trying to make tooling to automatically migrate things with rename awareness and similar to preserve snapshots when migrating recordsizes, since send|recv will only downsize it for you. The other direction is, I think, pretty feasible, and would make life for people, say, testing a bunch of different recordsizes on their existing snapshots over time work much more conveniently.

Additional context

N/A

[shodanshok]

A lot of time has been spent, at least by me, on trying to make tooling to automatically migrate things with rename awareness and similar to preserve snapshots when migrating recordsizes, since send|recv will only downsize it for you.

Maybe I missed something, but how can zfs send | zfs recv reduce recordsize?

While it is true that zfs send tank/zsrc@snap1 | zfs recv tank/zdst -o recordsize=32k creates tank/zdst with 32K recordsize, the transferred files actually have the original recordsize (128K in this case). Are you talking about a large_record source (>1MB records) and a smaller, default recordsize (128K) destination?

Thanks.

[rincebrain]

If you do zfs send foo/bar@snap1 and foo/bar has recordsize > 128k, and did not use zfs send -L, it will chunk them up into 128k records.

[shodanshok]

Thanks for explaining. I agree that the ability to "rechunk" records would be a good thing.