Allow resuming ZFS send to file from partial send stream #18022
Description
Describe the feature you would like to see added to OpenZFS
When doing an operation like zfs send -i @start tank/fs@end > somefile.zstream if the operation is interrupted it should be possible to supply a resume token to zfs send just as if the receive was happening on a "real" ZFS filesystem.
This would be implemented via the zstream tool:
zstream dump -t [file]
would read the ZFS stream file and find the last complete object record which can form a resume token.
Then
zstream truncate -s <token> [file]
would truncate the zstream file ready for resumption of the send stream.
The stream is then resumed via a simple append operation:
zfs send -s <token> -i @start tank/fs@end >> somefile.zstream
There is obviously a version of this process where zstream coordinates the entire endeavor - i.e. zstream recv [file] which would dump a resume token to stdout / a file if it doesn't finish successfully, and truncate the file automatically.
How will this feature improve OpenZFS?
Many users use ZFS send streams in binary form without a receiving filesystem and in particular do large file transfers this way. With direct connectivity to the receiving filesystem interruptions (i.e. network disconnections) can be handled, but when there is not direct connectivity - i.e. data may be moving via offline storage or stored into S3 buckets) then there is no way to resume the process except by resending the entire stream.
Notably for the offline transfer use-case, this avoids needing to keep multiple copies of the filesystem around just to survive network interruptions.
Additional context
As far as I know, based on how stream resumption works there's nothing stopping this being reality except the tooling? Am I missing anything?