Re: zfs and device name changes

[Takashi YAMAMOTO <yamt9999%gmail.com@localhost>]

hi,

On Mon, Jun 1, 2026 at 8:56 PM Simon Burge <simonb%netbsd.org@localhost> wrote:
>
> Hi Takashi,
>
> Takashi YAMAMOTO wrote:
>
> > hi,
> >
> > On Tue, Mar 24, 2026 at 9:58 AM Simon Burge <simonb%netbsd.org@localhost> wrote:
> > >
> > > Hi Takashi,
> > >
> > > Takashi YAMAMOTO wrote:
> > >
> > > > [ ... ]
> > > > https://github.com/yamt/netbsd-src/commit/32283c2e362034301c3da218a05849c04ee20c2a
> > >
> > > [ ... ]
> > > https://github.com/snarkophilus/src/blob/zfsboot/external/cddl/osnet/dist/uts/common/fs/zfs/vdev_disk.c
> > >
> > > Your device_is_eligible_for_vdev() has overlap with what RAIDframe does.
> > > I introduced a "storagepool" concept which Chuck didn't really like:
> > >
> > > https://mail-index.netbsd.org/tech-kern/2022/08/12/msg028311.html
> >
> > i wasn't aware of the effort. thank you.
>
> > i'm not sure if D_STORAGEPOOL concept is generic enough to teach every
> > drivers either.
> > for zfs, the actual requirement is something like just "large enough".
> > (cf. SPA_MINDEVSIZE)
> >
> > if we take that approach, i guess it should be visible to userland. (eg. libzfs)
> > and probably for the corresponding cdev too.
>
> I don't have a good suggestion on how to handle this.  My D_STORAGEPOOL
> concept was "is this a disk type device that can provide storage to a
> higher layer", whether that be RAIDframe, ZFS or LVM or whatever.  It
> seemed wrong having the same list in both RF and ZFS.
>
> Suggestions on how to better handle this are most welcome :)
>
>
> > > Now that you're looking at ZFS in more detail, I will try to make some
> > > movement on my ZFS changes.
> >
> > (asking without looking at your code yet)
> > is it based on freebsd's one?
>
>
> > i hope it doesn't rely on spa_config_load, which has been retired in openzfs.
>
> Are you able to try https://www.NetBSD.org/~simonb/zfs-vdev-disk-20260601.diff ?
> This is my previous diff for vdev_disk.c, but incorporates some of your
> changes and also has a little refactoring to make it look more like the
> current openzfs vdev_geom.c in structure so hopefully will make future
> migration to openzfs easier.

i will test it when/if i have a chance.
but please don't bother to wait for me.

>
> It's a little more complex than what you had, but hopefully it works the
> same as you expect.
>
> Cheers,
> Simon.