I have a high-iops pool formed by a bunch of heterogenous ssds (different brands, sizes, etc). This is an awesome idea but my write performance is only about 18MB/s (using fio test) but my read speed is > 680MB/s. I am wondering if I have a specific disk that is going bad or has some very slow speeds. How can I test read/write performance to each specific ssd? I’d prefer not to dismantle the pool. Is there some way to use the /dev/sdag or something to perform a read / write test?
How are the disks combined: like simple-concatenation, or RAID5/Z/6/Z2/10?
(Edit: Now I see the Vertex 3’s in there. I don’t know what your problem is technically… but those things are ancient and had dodgy write speeds even when new)
Oh my goodness. Wrong forum LOL. Sorry. Agree those vertex guys are ancient. Just for FYI, they are JBOD managed by Unraid. meant to post this on unraid forum.
Ticking timebombs in the pool … had three ocz in my laptop, one did not survive win xp installation Nr48. got RMA to Samsung256gb, that was faster as the other 2 ocz in raid 0.
I’m almost sure the problem is with sector size. Those SSDs report sector size of 512e, but they are in reality 4k or 16k sector size devices. I believe Samsung Evo are 4k
If your filesystem assumes 512 sector size, you may experience 8x to 16x write amplification, wasting the endurance and bringing performance to its knees; seeing worse than HDD performance is not impossible.
With zfs you could override the sector size when adding the device to the pool with ashift parameter. There might be something similar with whatever filesystem you are using.
Are there any modern file systems that still write in 512-byte sectors? AFAIK at least ext4 and NTFS do not do that, and never have in default configurations.
Good question. I’m not sure. This, however, would explain why not many people see the effects and why manufacturers can claim 512e without needing to do much work.
The other factor that used to matter was alignment, but this is irrelevant today; modern SSDs can mitigate that internally.
