Re: ZFS Bogosity

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

mlelstv%serpens.de@localhost (Michael van Elst) writes:

> gdt%lexort.com@localhost (Greg Troxel) writes:
>
>>David Brownlee <abs%absd.org@localhost> writes:
>>> https://gnats.netbsd.org/57583
>
>>Do you think this is just a bug that  it fails to look at wd3e
>>etc. wrongly if there is /dev/zfs?
>
> The code scans all devices in the specified device directory, unless
> it's /dev/. Then it uses sysctl hw.disknames to enumerate disk devices,
> and it doesn't care about disklabel partitions.

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

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.

What else cares about hw.disknames?

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.

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
.

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