Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 07 Feb 2014 15:23:15 -0600
From:      Mark Felder <feld@FreeBSD.org>
To:        freebsd-fs@freebsd.org
Subject:   Re: Using the *real* sector/block size of a mass storage device for ZFS
Message-ID:  <1391808195.4799.80708189.5CAD8A4E@webmail.messagingengine.com>
In-Reply-To: <1487AF77-7731-4AF8-8E44-FF814BB8A717@ebureau.com>
References:  <1487AF77-7731-4AF8-8E44-FF814BB8A717@ebureau.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Fri, Feb 7, 2014, at 14:44, Dustin Wenz wrote:
> We have been upgrading systems from FreeBSD 9.2 to 10.0-RELEASE, and I'm
> noticing that all of my zpools now show this status: "One or more devices
> are configured to use a non-native block size. Expect reduced
> performance." Specifically, each disk reports: "block size: 512B
> configured, 4096B native".
> 
> I've checked these disks with diskinfo and smartctl, and they report a
> sector size of 512B. I understand that modern disks often use larger
> sectors due to addressing limits, but I'm unsure how ZFS can disagree
> with these other tools.
> 
> In any case, it looks like I will need to rebuild every zpool. There are
> many thousands of disks involved and the process will take months (if not
> years). How can I be I sure that this is done correctly this time? Will
> ZFS automatically choose the correct block size, assuming that it's
> really capable of this?
> 
> In the meantime, how can I turn off that warning message on all of my
> disks? "zpool status -x" is almost worthless due to the extreme number of
> errors reported.
> 

ZFS is doing the right thing by telling you that you should expect
degraded performance. The best way to fix this is to use the gnop method
when you build your zpools:

gnop create -S 4096 /dev/da0
gnop create -S 4096 /dev/da1
zpool create data mirror /dev/da0.nop /dev/da1.nop

Next reboot or import of the zpool will use the regular device names
with the correct ashift for 4K drives.

The drive manufacturers handled this transition extremely poorly.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1391808195.4799.80708189.5CAD8A4E>