svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[John Baldwin]

On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote:
> On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
> > Please persuade me on technical grounds why ashift, a property
> > intended for address alignment, should not be set in this way. If your
> > answer is "I don't know but you are still wrong because I say so" I
> > will respect it and back it out but only until I/we discuss the
> > question with upstream ZFS developers.
> 
> No. You persuade me why changing ashift in ZFS, which, as the comment
> clearly states is "device's minimum transfer size" is better and not
> hackish than presenting the disk with properly configured sector size.
> This can not only affect disks that still use 512 bytes sectors, but
> doesn't fix the problem at all. It just works around the problem in ZFS
> when configured on top of raw disks.
> 
> What about other file systems? What about other GEOM classes? GELI is
> great example here, as people use ZFS on top of GELI alot. GELI
> integrity verification works in a way that not reporting disk sector
> size properly will have huge negative performance impact. ZFS' ashift
> won't change that.

I am mostly on your side here, but I wonder if GELI shouldn't prefer the 
stripesize anyway?  For example, if you ran GELI on top of RAID-5 I imagine it 
would be far more performant for it to use stripe-size logical blocks instead 
of individual sectors for the underlying media.

The RAID-5 argument also suggests that other filesystems should probably
prefer stripe sizes to physical sector sizes when picking block sizes, etc.

-- 
John Baldwin