On Wed, 26 Feb 2020 at 18:18, Greg Troxel <g...@lexort.com> wrote:
>
> Staffan Thomén <d...@shangtai.net> writes:
>
> I should point out that I am underclued on zfs and windows both.
>
> > I recently wanted to set up backup of a (snapshot of a) zvol that I
> > had exported via iscsi to a windows machine, and got stumped because
> > windows didn't just create a ntfs filesystem on the volume, it also
> > added a partition table and so mount_ntfs and ntfs-3g couldn't find
> > the filesystem on it.
>
> Once you export a zvol via iscsi, then it makes sense to methat the system
> attaching it sees it as a disk drive.
>
> > 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.
>
> > My other thought was using vnconfig, but that doesn't seem like the
> > right tool either.
>
> It seems sensible to me; vnconfig takes a file and tells the system to
> treat it like a disk. I don't know if doing vnconfig on a zvol works
> right, but it doesn't feel broken. Once you do this then if there is a
> gpt then the partitions should show up as dkN, I'd expect.
>
> The other thing you can do is export the zvol snapshot via iscsi and use
> an iscsi initiator on netbsd to mount it. I suspect this amounts to
> about the same thing as vnconfig.
>
> > This left me with a couple of questions, is dk the right fit for
> > getting at partitions on logical volumes? Could a tool be written that
> > does this so we wouldn't have to load down dkctl with features that
> > aren't really related to disks or is dk* not the right device and a
> > new driver is needed? Have I just missted something?
>
> I think you are only troubled by not wantting to use vnconfig, whose
> purpose is to turn a file into a disk, so that you can then do all the
> things with it that you normally do with disks.
That's all true; only gpt is capable of looking into the zvol structure:
...
gpt show /dev/zvol/rdsk/pail/nbsd1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 2048 1 GPT part - 5808c8aa-7e8f-42e0-85d2-e1e90434cfb3
2082 30686 2 GPT part - Windows reserved
32768 8355807 3 GPT part - af9b60a0-1431-4f62-bc68-3311714a69ad
8388575 32 Sec GPT table
8388607 1 Sec GPT header
...
However, neither vnconfig, nor dkctl do:
# dkctl /dev/zvol/rdsk/pail/nbsd1 listwedges
dkctl: /dev/zvol/rdsk/pail/nbsd1: listwedges: Inappropriate ioctl for device
# vnconfig -c vnd0 /dev/zvol/rdsk/pail/nbsd1
vnconfig: /dev/rvnd0: VNDIOCSET: Operation not supported
which is fair enough; the suggestion to export it via iSCSI and then
use the initiator to look at it should work, but 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.
--
----
