hi, On Mon, Jun 1, 2026 at 8:56 PM Simon Burge <[email protected]> wrote: > > Hi Takashi, > > Takashi YAMAMOTO wrote: > > > hi, > > > > On Tue, Mar 24, 2026 at 9:58 AM Simon Burge <[email protected]> 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.
