Peter Blok writes:
Hi Peter,
> I have the same issue on a couple of servers. I haven’t found a way to
> correct this, but it wasn’t any problem upgrading and after the
> upgrade everything worked ok.
So you're telling that upgrading from stable/12 to stable/13 using
https://docs.freebsd.org/en/
Hello everyone,
I posted a question on (
https://forums.freebsd.org/threads/zfs-replication-interrupted-and-resumed-missing-snapshots.85666/
)
Which I now think is a bug in zfs send/receive for 13.1-RELEASE
Essentially, an interrupted & restarted receive does not create all snapshots
from the
It's not a bug. The problem is that you can't combine zfs send -R and also
zfs recv -s . The former creates several independent send streams. But
the latter generates a token that will only resume a single stream. And
there's no way to fix the problem given ZFS's design. If the send gets
interrup
Yes, no issues except that on one server I forgot to do the etcupdate -B. It
still worked ok, but an extra zpool wasn’t imported.
Many of the servers were out of reach and headless, so I was pretty happy it
worked so well.
One aspect to consider: you need to do this with a kernel config that co
Understood.
Could this be documented in the man-pages (maybe near the zfs-send “-t” option)?
Also I think, it would be “a nice to have feature” if this throws an error
either at the receiving or sending side.
(May be the sending options should be part of the transmission stream and the
receiver
Yeah, it would be great if it could raise an error. I've run into
this problem before. However, I can't figure out how. It's not easy,
because the two incompatible flags apply to separate commands. The
only way I can guess how to do it would be to add a flag to the send
stream that says "the st
Sometime this AM (> 07:10:39 PST8PDT, < 08:15 2022/7/4) the anonymous git
repo seems to have developed an issue:
# git remote -v
freebsd anon...@git.freebsd.org:src.git (fetch)
freebsd anon...@git.freebsd.org:src.git (push)
# git pull -v
Fssh_kex_exchange_
