receive of a send -p stream doesn't need to try renaming snapshots
A stream created with zfs send -p -I contains properties of all snapshots of a given dataset as opposed to only properties of snapshots in a given range.
Not only this is suboptimal but the receive code also does not filter properties by the range. So, properties of earlier snapshots would be updated even though the snapshots themselves are not in the stream (just their properties).
Given that modifying the snapshot properties requires a TXG sync and that the snapshots are updated one by one the described behavior may lead to a sever performance penalty.
Updated by Andriy Gapon over 5 years ago
The previous review request has been discarded and a new one has been created: https://reviews.csiden.org/r/269/
The experience has shown that the proposed solution was incomplete and, more importantly, changing the stream content may have severe consequences if the receiving side is not prepared to handle that.
So, the new approach does not make any changes to the stream content (and, thus, to the sending side). Instead it's the receiving side that gets optimised.
Last note is that the effect of using '-p' option is not sufficiently documented at the moment.
Updated by Electric Monk almost 5 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 471a88e499c660844f4590487ce7c4d5a7090294 Author: Andriy Gapon <avg@FreeBSD.org> Date: 2017-04-07T22:19:28.000Z 5380 receive of a send -p stream doesn't need to try renaming snapshots Reviewed by: Paul Dagnelie <email@example.com> Reviewed by: Matt Ahrens <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>