NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ZFS Bogosity



On Sun, Aug 13, 2023 at 08:22:08PM -0400, Greg Troxel wrote:
> 
> Given that wd3e is a name for a disk special file with defined size, it
> would seem that we should change that.  It seems to make just as much
> sense to probe wd3[a-p] as it does to probe wd3 (which is wd3d).

You can change the code to scan partitions instead. It gets a bit
more complicated, if wedges are involved.


> Alternatively, I see that we add wedges to hw.disknames. My system has
> a NetBSD boot image on a flash drive this minute, and:
>   hw.disknames = wd0 cd0 sd0 dk0 dk1
> so if we add dk0, which is really no different logically than sd0a, it
> seems like we should add disklabel partitions like wd3e.

The sysctl value reflects the device drivers from the autoconfig
process. It has no knowledge about disk content. This discrepancy
between disklabel partitions and wedges is maybe the largest problem
of wedges. You can avoid this by ignoring and phasing out disklabel
partitions (which only work for "small" disks anyway) and use wedges
also to handle the bsd disklabel.


> It also seems odd to special case /dev, vs using the dir if passed and
> doing hw.disknames->dev if not, but it seems best to minimally munge
> upstream.

That's an optimization to avoid scanning and probing all entries
in /dev/ which can take some time and may have unwanted side effects
when you scan non-disk devices.


> What happens on FreeBSD?  Are they so firm on gpt-only, geom and
> zfs-on-whole disk that this doesn't come up?  It seems obvious that
> people easing into zfs are going to use partial disks, if only as
>   / sw /usr on ffs, and
>   rest as sole storage for a pool
> .

For ZFS it rarely makes sense to use partitions. You need this as
a workaround to allow bootstrap without ZFS support in the boot
process, and you need it to exchange media with other systems
that use the partition table as identifier (but who uses disklabel?).


> 
> > You can also cache devices, then the pool devices are just used as
> > stored in the cache instead of scanning all disks for labels. But
> > that doesn't work nicely with wedges or anything else with changing
> > device units.
> 
> I found that my single pool tank0 with a single component wd0f has a
> cache file in /etc/zfs/zpool.cache.   But that seems not a general
> solution for import.

That is the general solution of ZFS to avoid the time consuming scanning
of /dev/ at startup, and you could arrange disk devices into something
like /dev/disk to avoid side effects on non-disk devices.... You see,
it's a design for something else.

Or you could arrange for "volume labels" to be visible in the filesystem
(e.g. use devpubd to create symlinks for wedges, or invent a device
filesystem that is filled by the kernel) and let zfs scan these.


Makeing zfs scan disklabel partitions derived from hw.disknames seems
to be the easier method though.



Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."


Home | Main Index | Thread Index | Old Index