Re: ZFS question

It's a little more than that.  FreeBSD has a method by which each GEOM
thing is tested (called "tasting" in the documentation) and a consumer is
chosen.  tasting automatically reads the first few (and, I believe, last
few) bytes of each GEOM when it comes online.  GPT partition GEOM will
attach if it has a GPT label... and will create providers for each
partition.  Each partition is then "tasted" and consumers get a chance to
claim them.  Consumers can be other label-like constructs or filesystems...
but filesystems don't just auto mount.

For UFS (and most filesystems) they need to be in /etc/fstab.  For ZFS, it
used to be /etc/zfs/zpool.cache (but I hear noises that some other method
is used).   In deference to the below, I believe that ZFS recognises it's
disks with a taste (as ZFS VDEVS) and then can determine where they belong
by reading the ZFS header.  I don't believe the GUID is part of this --- it
seems to remember the device that was last used as defaults.

Now... the reason devices seem to use GUID mounts is that GUID is the
highest priority taster (or somesuch).  If devices move around, ZFS finds
the drive by GUID first.  If you turn off GUID (with
kern.geom.label.gptid.enable=0 and/or kern.geom.label.disk_ident.enable=0
in /boot/loader.conf) you'll get them mounted as daXsY or adaXsY.  I
usually put this in lader.conf as the "names" are shorter and display
better in the table, to my eyes.

You can do this with UFS, in a way, by either using the GUID mount (which
doesn't change as the disk moves) or by creating either a UFS or a GPT
label for the filesystem.  It will then appear in /dev/ufs/<label> or
/dev/gpt/<label> as appropriate.  If they type of the GPT partition is
"freebsd" and you BSD label that partition, /dev/gpt/<label>[abcdefg] may
appear, as appropriate.

Using either GUID naming _or_ using GPT/UFS naming _or_ using ZFS can even
allow you to change controllers --- that is: move a disk from SATA to SAS
to (even) USB.  I have recently even got a NVMe-to-USB3 enclosure for
various reasons ... and this also works.

GEOM is truly one of the GREAT FreeBSD abstractions... that is more than
the sum of its parts.

On Thu, Aug 5, 2021 at 3:45 PM Alan Somers <asomers@freebsd.org> wrote:

> Each drive has a label containing the drive's guid and the guid of every
> other drive in the same top level vdev .  During import, ZFS searches every
> geom provider to find matching guids.  If the drives have the same names as
> they used to, then the import goes faster. But ZFS always checks the guids
> during import .
>
> On Thu, Aug 5, 2021, 2:26 PM joe mcguckin <joe@via.net> wrote:
>
> > How does ZFS keep track of drives in a dataset or VDEV? If I rearrrange
> > the drives in a chassis, somehow ZFS is able to make sense of the
> scrambled
> > drives and
> > mount the dataset.
> >
> > Clearly ZFS is tracking the drives. How does it refer to the drives
> > internally? By UUID, Drive Label?  On some  OS’s (Linux) there are many
> > options for specifying which drives make up a VDEV: UUID, Partition
> Label,
> > etc. On other OS’s, these schemes might not exist
> > (think moving drives from Linux to FreeBSD, for example).
> >
> > I’ve noticed that on Linux, drive identifiers (sda, sdb, etc) move around
> > after reboots. How does ZFS cope with this?
> >
> > Does each drive (or partition) have a header that tells ZFS that this
> > entity is ‘drive 2 of VDEV foo’?
> >
> > Thanks,
> >
> > Joe
> >
> > Joe McGuckin
> > ViaNet Communications
> >
> > joe@via.net
> > 650-207-0372 cell
> > 650-213-1302 office
> > 650-969-2124 fax
> >
> >
> >
> >
>