Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS

On 06.04.22 18:34, egoitz@ramattack.net wrote:
>
> Hi Stefan!
>
>
> Thank you so much for your answer!!. I do answer below in green bold 
> for instance... for a better distinction....
>
>
> Very thankful for all your comments Stefan!!! :) :) :)
>
>
> Cheers!!
>
>
> El 2022-04-06 17:43, Stefan Esser escribió:
>
>> ATENCION
>> ATENCION
>> ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. 
>> No pinche en los enlaces ni abra los adjuntos a no ser que reconozca 
>> el remitente y sepa que el contenido es seguro.
>>
>> Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net:
>>> Hi Rainer!
>>>
>>> Thank you so much for your help :) :)
>>>
>>> Well I assume they are in a datacenter and should not be a power 
>>> outage....
>>>
>>> About dataset size... yes... our ones are big... they can be 3-4 TB 
>>> easily each
>>> dataset.....
>>>
>>> We bought them, because as they are for mailboxes and mailboxes grow and
>>> grow.... for having space for hosting them...
>>
>> Which mailbox format (e.g. mbox, maildir, ...) do you use?
>> *I'm running Cyrus imap so sort of Maildir... too many little files 
>> normally..... Sometimes directories with tons of little files....*
>>
>>> We knew they had some speed issues, but those speed issues, we 
>>> thought (as
>>> Samsung explains in the QVO site) they started after exceeding the 
>>> speeding
>>> buffer this disks have. We though that meanwhile you didn't exceed it's
>>> capacity (the capacity of the speeding buffer) no speed problem 
>>> arises. Perhaps
>>> we were wrong?.
>>
>> These drives are meant for small loads in a typical PC use case,
>> i.e. some installations of software in the few GB range, else only
>> files of a few MB being written, perhaps an import of media files
>> that range from tens to a few hundred MB at a time, but less often
>> than once a day.
>> *We move, you know... lots of little files... and lot's of different 
>> concurrent modifications by 1500-2000 concurrent imap connections we 
>> have...*
>>
>> As the SSD fills, the space available for the single level write
>> cache gets smaller
>> *The single level write cache is the cache these ssd drivers have, 
>> for compensating the speed issues they have due to using qlc memory?. 
>> Do you refer to that?. Sorry I don't understand well this paragraph.*

A single flash cell can be thought of as a software adjustable resistor 
as part of a voltage divider with a fixed resistor. Storing just a 
single bit per flash cell allows very fast writes and long lifetimes for 
each flash cell at the cost of low data density. You cheaped out and 
bough the crappiest type of consumer SSDs. These SSDs are optimized for 
one thing: price per capacity (at reasonable read performance). They 
accomplish this by exploiting the expected user behavior of modifying 
only small subsets of the stored data in short bursts and buying (a lot 
more capacity) than they use. You deployed them in a mail server facing 
at least continuous writes for hours on end most days of the week. As 
average load increases and the cheap SSDs fill up less and less 
unallocated flash can be used to cache and the fast SLC cache fills up. 
The SSD firmware now has to stop accepting new requests from the SATA 
port and because only ~30 operations can be queued per SATA disk and the 
ordering requirements between those operations not even reads can be 
satisfied while the cache gets slowly written out storing four bits per 
flash cell instead of one. To the user this appears as the system almost 
hanging because every uncached read and sync write takes tens to 100s of 
milliseconds instead of less than 3ms. No amount of file system or 
driver tuning can truly fix this design flaw/compromise without severely 
limiting the write throughput in software to stay below the sustained 
drain rate of the SLC cache. If you want to invest time, pain and 
suffering to squish the most out of this hardware look into the ~2015 
CAM I/O scheduler work Netflix upstreamed back to FreeBSD. Enabling this 
requires at least building and installing your own kernel with this 
feature enabled, setting acceptable latency targets and defining the 
read/write mix the scheduler should maintain.

I don't expect you'll get satisfactory results out of those disks even 
with lots of experimentation. If you want to experiment with I/O 
scheduling on cheap SSDs start by *migrating all production workloads* 
out of your lab environment. The only safe and quick way out of this 
mess is for you to replace all QVO SSDs with at least as large SSDs 
designed for sustained write workloads.