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 -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
