Date: Fri, 11 Sep 2015 13:33:21 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: "William A. Mahaffey III" <wam@hiwaay.net> Cc: FreeBSD Questions !!!! <freebsd-questions@freebsd.org> Subject: Re: followup storage question Message-ID: <alpine.BSF.2.20.1509111317420.83821@wonkity.com> In-Reply-To: <55F2ED46.6060708@hiwaay.net> References: <55F2D086.6060509@hiwaay.net> <alpine.BSF.2.20.1509110821560.6365@wonkity.com> <55F2ED46.6060708@hiwaay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Sep 2015, William A. Mahaffey III wrote: > On 09/11/15 09:31, Warren Block wrote: >> On Fri, 11 Sep 2015, William A. Mahaffey III wrote: >> >>> The Wiki page https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE >>> illustrates using gnop to enforce 4K alignment of gpt partitions for >>> subsequent use by ZFS. However the gpart commands also use the '-a 4k' >>> arguments, aligning partitions on 4k boundaries as I understand things. Is >>> the gnop command also necessary ? TIA & have a nice weekend. >> >> These are two separate things. gnop(8) is (was) used to force ZFS to use a >> 4K block size. That just means it transfers data in multiples of 4K, not >> necessarily aligned with the 4K sectors on the drive. gpart(8)'s -a flag is >> used to force partitions to begin in alignment with the 4K sectors on the >> drive. >> > > Hmmmm .... OK, however if I carefully 'gpart -a 4k' the underlying partitions > aligned, then wouldn't the resulting ZFS above also be aligned ? Again, these are two different things. Alignment is making sure that the filesystem blocks align with the device blocks. Otherwise, a 4K request from the filesystem could force the drive to read or write two 4K hardware blocks. This can cut performance in half. The gnop trick is to force the *size* of ZFS blocks to be 4K. Otherwise, the filesystem could end up reading 512-byte blocks on a 4K drive. The drive would read and cache a 4K block, but the filesystem would have to request it in eight 512-byte pieces. Writes are not good in this situation either, although the drive might combine them to avoid rewriting the same disk block eight times. Matching the filesystem block size with the disk block size avoids that additional overhead.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1509111317420.83821>