Re: dk for z/lvm volumes?

[Greg Troxel <gdt%lexort.com@localhost>]

Staffan Thomén <duck%shangtai.net@localhost> writes:

> 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).

I read some more, and it seems a zvol is supposed to be like a device.

So I am beginning to think you are right, and read-only disks seem like
an ok thing.  Arguably the driver for the RK05 should check the physical
write-protect switch and make it RO if so :-)

I guess you can start reading dkctl sources.    It can't be that
complicated, but then you'll have to read the kernel ioctl that it invokes.

>>> 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.

It is.

vnconfig is less kludgy and may be a good workaround, even if we decide
that dkctl makewedges  should work.

Does dkctl work on a zvol  that is not read only?


>> [...] 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.

I had the same thought.  With bup, it may well work with dedup, but
that's not a tape thing.