Replying to you both in one here.. Chavdar Ivanov wrote:
On Wed, 26 Feb 2020 at 18:18, Greg Troxel<gdt%lexort.com@localhost> wrote:Staffan Thomén<duck%shangtai.net@localhost> writes:I couldn't coax dkctl to create dk devices for the gpt on the volume, and dkctl seems like a bit of a mismatch for creating arbitrary dk:s anyway as it seems mostly directed at bare drives (cache settings etc).From the NetBSD point of view there is a zvol, and you are letting iscsi manage it. So there's nothing to tell netbsd to read a gpt/mbr and deal.
Indeed, but that's where dkctl comes in with makewedges to tell netbsd to scan for wedges, but that doesn't work (wonderfully it says "Read-only file system" on the (admittedly read only) volume snapshot).
The other thing you can do is export the zvol snapshot via iscsi and use an iscsi initiator on netbsd to mount it.
This would work, but seems like a bit of a pretzel of a solution. What I'm mostly wondering is if it wouldn't be sensible to extend dk to be able to be used with volumes.
> [...] perhaps looking at it
from the Windows initiator would have more sense - unless the backup is supposed to be done on the NetBSD host, in which case the suggestion would be to # zfs send pail/nbsd1> nbsd1.zfsfs and then backup the resulting zfs stream, which you can cmpress of course.
Yup, this would definitely work, but it's terribly inefficient on tape use since I can't do block-level differential backups. Whenever the volume filesystem changes, I have to backup the entire thing.
Staffan