Re: ZFS Bogosity

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

Michael van Elst <mlelstv%serpens.de@localhost> writes:

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

I read that as "changing hw.disknames is difficult and likely to lead to
trouble".

In this case, wedges show up as logical disks in hw.disknames, so it's
really that partitions aren't disks.  Which is fine, except some code
assumes that only full disks matter which is wrong.

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

Do you mean "create dkN entries from the disklabel"?  That doesn't
happen by default.

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

Makes sense, but the man page should probably be louder about this,
then.  I'll try to get this into the zfs howto.

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

I still use disklabels on disks that are <= 2T, and I don't see that as
really odd.

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

I do have /etc/zfs/tank0 with:

  $ ls -l /etc/zfs/tank0/
  total 0
  lrwxr-xr-x  1 root  wheel  9 Feb 17  2021 wd0f -> /dev/wd0f

and that seemed to work.

Yes, the cache solution works fine on boot.  But it does not solve
export/import so cleanly.

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

Yes, that seems not to have any real downsides and would make it behave
as expected.

We probably do need to make sure we don't alias /dev/wd3e and /dev/dk7
which is a wedge created from it.  But presumably there is header with a
uuid and zfs already copes.