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).

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.

Thanks,
Tom
_______________________________________________
opensolaris-arc mailing list
[email protected]

Reply via email to