On Mon, 10 Oct 2011, Jim Klimov wrote:

Thus I proposed the second idea with a code-only solution
to optimize performance (force user-configured minimal
data block sizes and physical alignments) where metadata
blocks would remain 512 bytes because the pool is formally
ashift=9 - and on-disk data would be compatible with other
pools and OSes boasting ZFS.

The problem with this approach is that it results in the same write-amplification that ashift=12 is trying to avoid. If the underlying hardware will still write 4K blocks then it will still be writing 4K blocks. Storage space is saved but much/most of the performance benefit restored by ashift=12 goes away, or the problem becomes even worse due to concurrent updates which are coalesced at the hardware level.

File data is still usually much larger than 4K blocks so most performance problems because of the 4K blocks must be due to writing metadata.

Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
zfs-discuss mailing list

Reply via email to