tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: zfs and device name changes
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.
It's a little more complex than what you had, but hopefully it works the
same as you expect.
Cheers,
Simon.
Home |
Main Index |
Thread Index |
Old Index