On 06/ 2/10 04:08 PM, Tom Erickson wrote:
Sebastien Roy wrote:
I only have one comment regarding the zfs pool version handling:
C.2. Version Compatibility
To get the full benefit of the options described in this case, the ZFS
pool needs to be at version 22 (received properties) or later. Before
that, the following options behave differently:
receive -o If the specified property is present in the send stream,
it is replaced by the value specified after the -o option,
since the sent value cannot be overridden locally.
receive -x If the specified property is present in the send stream,
it is simply ignored, since it cannot be overridden
locally.
send -b This option is ignored. Received properties cannot be sent
in favor of local settings because the two cannot be
distinguished. All datasets appear to have never been
received and their settings are sent as original
properties.
Is there not a concern that the handling of the latter two usages will
lead to surprising results if the administrator is not immediately
aware of the version of the appropriate pool? Would failing these
operations be a viable option?
In the 'receive -x' case, the behavior is not surprising. On all pool
versions, -x says treat the specified property as if it had been
excluded from the send stream. The only difference is that before
version 22, the received property value is not saved, but it would not
have affected the behavior of the dataset anyway. The effective behavior
resulting from receive -x is the same on all pool versions. Since -x is
useful on all pool versions, I don't think it makes sense to fail the
command before version 22 (that would be more surprising).
Okay.
In the 'send -b' case, the -b doesn't do anything useful before version
22. The option assumes that we can distinguish received properties, so I
think it makes sense to fail the command before version 22. If no one
objects, I'll go with Sebastian's suggestion and fail 'send -b' with an
error message before version 22.
Yes, that makes sense to me. +1 on the case given this clarification.
-Seb
_______________________________________________
opensolaris-arc mailing list
[email protected]
