到目前为止,我一直在使用ZFS,没有遇到太多麻烦,但是今天我遇到了一个非常奇怪的错误。我基本上是在进行增量发送(加密的硬盘驱动器),其内容如下:
$ sudo zfs send -w -v -i "#myoldsnap" "mylocalzfspool/encrypted_home@mynewsnap" | sudo zfs recv myexternalpool/backup/Laptop -F
send from mylocalzfspool/encrypted_home#myoldsnap to mylocalzfspool/encrypted_home@mynewsnap estimated size is 13.8G
total estimated size is 13.8G
cannot receive incremental stream: IV set guid missing. See errata 4 at https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-ER.但是,如果我用#myoldsnap代替@myoldsnap (也就是说,如果我使用快照而不是书签),那么它可以工作.但是,我更喜欢使用书签,因为以后我可能会删除快照以节省空间。
为了防止有帮助,下面是我在外部磁盘上有我的旧快照,在本地磁盘上有我的书签的证据:
$ sudo zfs list -t snapshot -o name
NAME
mylocalzfspool/encrypted_home@myoldsnap
mylocalzfspool/encrypted_home@mynewsnap
[...]
myexternalpool/backup/Laptop@myoldsnap
$ sudo zfs list -t bookmark
NAME USED AVAIL REFER MOUNTPOINT
mylocalzfspool/encrypted_home#myoldsnap - - - -
mylocalzfspool/encrypted_home#mynewsnap - - - -知道为什么在书签上失败了吗?通常我没有太多的问题,同时我只是在外部池上创建了另一个卷,我曾经尝试用一个不支持加密的旧版本打开ZFS,我只是得到了一个错误.但这是我唯一能想到的。
发布于 2023-04-22 20:33:55
我知道这篇文章很旧,但我今天遇到了这个问题,我想补充一下我的发现。
结果发现,在我的例子中,发送书签创建了一个糟糕的流,可以通过源代码上的zstreamdump进行检查:
zfs send -w -i "#oldsnap" "tank/home@newsnap" | zstreamdump | grep from_ivset_guid
from_ivset_guid = 0x0但是,快照将创建一个正确的"IV set guid“值:
zfs send -w -i "@oldsnap" "tank/home@newsnap" | zstreamdump | grep from_ivset_guid
from_ivset_guid = 0x968b62ce478cf1源Ubuntu比目标稍早一些,所以我尝试了apt upgrade,然后尝试了zpool upgrade tank,两者都没有改善情况。
但是,删除并重新创建系统升级后的书签确实解决了我的问题。
https://unix.stackexchange.com/questions/646769
复制相似问题