RFC: Suggesting ZFS "best practices" in FreeBSD

John jwd at FreeBSD.org
Tue Feb 26 20:42:58 UTC 2013


----- Zaphod Beeblebrox's Original Message -----
> On Wed, Jan 23, 2013 at 6:18 AM, Peter Jeremy <peter at rulingia.com> wrote:
> 
> > On 2013-Jan-22 17:27:13 -0800, Michael DeMan <freebsd at deman.com> wrote:
> 
> > >#2.  Ensure a little extra space is left on the drive since if the whole
> > drive is used, a replacement may be a tiny bit smaller and will not work.
> >
> > As someone else has mentioned, recent ZFS allows some slop here.  But
> > I still think it's worthwhile carving out some space to allow for a
> > marginally smaller replacement disk.
> 
> I'm somewhat interested in this point.  Not that we should miss a few meg
> on a multi-terrabyte disk, but in my recent experience, all the drive
> manufacturers seem to "agree" on the number of sectors for a certain size
> of disk.  I'm just not sure we need to leave for the allowance of a smaller
> disk.  larger (than required) disks already work anyways.

>From the zpool manpage:

     disk    A block device, typically located under /dev.  ZFS can use indi-
             vidual slices or partitions, though the recommended mode of oper-
             ation is to use whole disks. A disk can be specified by a full
             path to the device or the geom(4) provider name. When given a
             whole disk, ZFS automatically labels the disk, if necessary.

...

         For pools to be portable, you must give the zpool command whole
         disks, not just slices, so that ZFS can label the disks with portable
         EFI labels. Otherwise, disk drivers on platforms of different endian-
         ness will not recognize the disks.

   And of course, if you look through the source, you'll see where ZFS
makes a distinction between slices & whole disks. I have not debugged
through it recently to see how much of it is currently in use.

   If you use dual-channel SAS drives with geom multipath, you need to be
clear whether your meta-data on disk from the different geoms collide... 

   Regardless of how the best practices is put together, make sure
folks are aware of the limitations/caveats of the different choices.

YMMV

Cheers!
John



More information about the freebsd-fs mailing list