New ZFS pool - some questions

omniscence

[H]ard|Gawd
Joined
Jun 27, 2010
Messages
1,311
I'm currently in the process of converting my main storage pool to ZFSonLinux. I finally (almost) decided that I would like to have an 11 disk RAIDZ3 pool over a 10 disk RAIDZ2 and 2x6 disk RAIDZ2 pool. My question however is: wouldn't it be better to create the pool with ashift=13 (yes, thirteen) if I wanted to add SSD SLOG and L2ARC later? I read (and it seems logical) that for pure SSD pools with modern drives ashift=13 yields better performance because the page size of such drives is now 8k. With ashift=13 the read-modify-write pattern that 4k accesses generate could be avoided, which would reduce IO latency.
 
All SSDs are very fast in comparison to HDDs. Even if you penalize the SSD slightly, it will still be fast. Why would you want to add SLOG and L2ARC? What kind of data are you storing, and what is the purpose of the storage server?
 
It is a general purpose storage pool, all kinds of data. While an SSD with a little penalty is still fast, the IO latency is a significant part of the achievable sync transfer rate with an SLOG device. The difference between ashift=12 read-modify-write pattern and ahift=13 write-only pattern may be as large as the difference between an enterprise SSD and a high-end consumer SSD. But I did not test this, that is why I'm asking.
 
there really is no difference between consumer and enterprise SSDs in terms of IO latency. typically the main difference is over provision and or better quality NAND.

at least that has been my experience after testing quite a few sata and sas ssd drives.

btw where did you read about ahisft=13? would like to read that article.

also brutalizer, all SSD pools still write better with a SLOG in place. the reason for this is while ZFS is/was forward thinking it still assumes that nothing will ever be faster than the SLOG. it really doesn't know how to function at peak efficiency when all the drives in the system are SSD. meaning, it is still fast as shit, don't get me wrong, however it could be even faster if some of the internal SPA sync functions were a bit smarter.
 
Back
Top