upgrade zfs-0.7.0

possibly you have not tested the correct direction (it's only broken from new to old)? it is very easily reproducible here.

I have tested in both directions, I didn't run "zpool upgrade" on the 0.7.1 updated host, maybe that is why it works.
 
no it is not. what I expect (and ZFS does in most cases) is backwards compatibility.
"Backward compatibility" means data created with older version of some software can be used by newer version of the same software.This is quite common.

But what you expect is "forward compatibility": data created by newer version of software (in this case zfs 0.7) to be usable by older version of software (zfs 0.6.5)...
 
"Backward compatibility" means data created with older version of some software can be used by newer version of the same software.This is quite common.

But what you expect is "forward compatibility": data created by newer version of software (in this case zfs 0.7) to be usable by older version of software (zfs 0.6.5)...

you are confusing stuff here / we are not talking about the same thing.

backwards compatibility also means stuff like "save in legacy format" (think of e.g. office software like LO writer), which is basically what ZFS does/has supported so far. we don't want to teach old ZFS versions to handle streams with new features (that WOULD be forward compatibility!), we want to teach the new ZFS to generate (BACKWARDS-)compatible streams which can be handled by old versions. backwards-compatibility in the sense of "ZFS 0.7 handles ZFS 0.6.5 streams just fine" is a different variant of backwards compatibility (the most common one, and the most needed one for upgrades in general).
 
So you mean 0.6.5->0.7 is backward compatibility, and 0.7->0.6.5 is backward compatibility too? No offense, but maybe you could find some time to read those two wiki-links I posted, because you are mixing things terribly.

"Legacy mode" is again something quite different (as you can read on wiki too):

"...It (legacy mode) differs from backward compatibility in that an item in legacy mode will often sacrifice newer features or performance..."
 
So you mean 0.6.5->0.7 is backward compatibility, and 0.7->0.6.5 is backward compatibility too? No offense, but maybe you could find some time to read those two wiki-links I posted, because you are mixing things terribly.

"Legacy mode" is again something quite different (as you can read on wiki too):

"...It (legacy mode) differs from backward compatibility in that an item in legacy mode will often sacrifice newer features or performance..."

(this will be my last answer here, as further arguing about semantics is a waste of time better spent on actually fixing this bug..)

yes. but I am not talking about putting ZFS into a legacy mode, I am talking specifically about zfs send, which is an export function, for which "backwards compatible" is the terminology for referring to "export in a way that the old version understands". if you don't believe me, check the documentation of any software that has such an export function (like any document, image or video editing software). breaking backwards compatibility in this context means exporting stuff in a way that the old version does not understand. for ZFS, this has usually been opt-in or at least opt-out. that it is not for ZFS 0.7 was an accident, which can hopefully be fixed. if you want, you can call it ABI/API/stream format stability instead of backwards compatibility, I don't care :p
 
OK, so let's close it so that you (ev. all Proxmox-team) call it "backward compatibility" (and I'll try to remember this peculiarity), but fortunately all other software-devs call it "legacy mode". Period.
 
OK, so let's close it so that you (ev. all Proxmox-team) call it "backward compatibility" (and I'll try to remember this peculiarity), but fortunately all other software-devs call it "legacy mode". Period.

(really last post, just because I found your post really rude / insulting and stumbled over this afterwards while bisecting)

https://github.com/zfsonlinux/zfs/blob/master/include/sys/zfs_ioctl.h#L156
This is not implemented as a feature flag, because the receiving side does not need to have implemented it to receive this stream; it is fully backwards compatible. We need a flag, though, because full send streams without it cannot necessarily be received as a clone correctly.

referring to exactly the code we are discussing here, using backwards compatible in exactly the way I described, written by one of the Delphix devs for OpenZFS ;) Period?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!