You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not entirely sure whether this is a "less-ideal feature" or an actual bug, but I noticed that send_pipe() (in ZfsDataset.py) appends the --compressed option to zfs send (if it's supported), which causes two notable things:
As per the manual"Streams sent with -c will not have their data recompressed on the receiver side using -o -compress=value. The data will stay compressed as it was from the sender." which prevents using different compression method on the receiver side, which is relatively common case; use fast lz4 in production and gzip for the backups for trading performance for saved space.
Since the stream is now already compressed by zfs send, it makes the "wrapping" compressor (defined by the zfs_autobackup's --compress flag) very inefficient since it now has to compress already compressed data rather than the raw, uncompressed source data.
Perhaps the inclusion of the --compressed option in zfs send should be removed, or at least made configurable?
The text was updated successfully, but these errors were encountered:
Yes indeed this is a problem now that we have --compress. Also i didnt realize sometimes the administrator might want to recompress on the other side.
We could either:
Disable it automaticly when the user specifies --compress.
Disable it by default and have an extra option called --zfs-compressed that enables zfs send --compressed.
I'm for the second option since i want to keep automatic setting guessing/magic to the minimum and we should let the administrator decide which function is desired.
Perhaps a warning when both --zfs-compressed and --compress are specified.
Anyone following this, let me know your opinion about this. Justice will be swift :)
The second option sounds better to me. It would also allow a scenario where compression to be applied only on the receiving side, which can be beneficial in cases where the network link is fast and the source host cpu is slow.
Not entirely sure whether this is a "less-ideal feature" or an actual bug, but I noticed that send_pipe() (in ZfsDataset.py) appends the
--compressed
option to zfs send (if it's supported), which causes two notable things:--compress
flag) very inefficient since it now has to compress already compressed data rather than the raw, uncompressed source data.Perhaps the inclusion of the
--compressed
option in zfs send should be removed, or at least made configurable?The text was updated successfully, but these errors were encountered: