Date: Thu, 5 Aug 2021 14:45:01 -0500 From: Alan Somers <asomers@freebsd.org> To: joe mcguckin <joe@via.net> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: ZFS question Message-ID: <CAOtMX2g68_UQTEUGT2TSp9A=DPNqjpHQxX9=mrNbC9X=y72Teg@mail.gmail.com> In-Reply-To: <F83EAFD3-9AA3-4407-8BE1-0675AEF40780@via.net> References: <F83EAFD3-9AA3-4407-8BE1-0675AEF40780@via.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000062500805c8d52802 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 scrambl= ed > 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=E2=80=99s (Linux) there ar= e many > options for specifying which drives make up a VDEV: UUID, Partition Label= , > etc. On other OS=E2=80=99s, these schemes might not exist > (think moving drives from Linux to FreeBSD, for example). > > I=E2=80=99ve noticed that on Linux, drive identifiers (sda, sdb, etc) mov= e around > after reboots. How does ZFS cope with this? > > Does each drive (or partition) have a header that tells ZFS that this > entity is =E2=80=98drive 2 of VDEV foo=E2=80=99? > > Thanks, > > Joe > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > > > > --00000000000062500805c8d52802--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2g68_UQTEUGT2TSp9A=DPNqjpHQxX9=mrNbC9X=y72Teg>