(L1 &) L2 & defer write latency (Native & Average unaffected!)
Posted: Sat Feb 04, 2023 12:00 pm
Hi guys,
at first let me make you my congratulations for this GREAT piece of software!
I'm an IT manager and I found it recently, searching for a product of this type for a particular project I'm setting up. And it fits my needs greatly way!
Because of my engineering formation and having the need of maximum reliability in my "critical" project, I've read ALL the "fuc**d" manual, documentation and FAQs, many posts here and then I have set up a testing system to try all the options, make some sintetic & real world benchmark and fine tuning at best for my needs...
It's during these tests that I found what I think it's a BUG or, at least, a bad documented behaviour that could be very dangerous if not well understood by users.
After many tests I was finally working with this (very good IMHO!) configuration:
- L1 R/W: 3 GB / 1 GB
- L2 R/W: (about...) 650 GB / 100 GB
- Block size: 32 KB
- Strategy: Read & Write
- Defer write: 1 sec
- Mode: Intelligent
- Options: FreeWritten, FlushSleep
- Prefetch: Disabled
- Volatile cache content: enabled
- Free cache on written: enabled
- Flush L1 to L2: disabled
As you can see this is a good performance strategy with an OPEN eye to security of data (volatile cache content, only 1 sec defer write latency, which makes the difference anyway!).
It's during the final tests that I found the BUG (or the not well documented behaviour!): defer write latency is complied *ONLY* by L1 cache, with L2 cache which will retain data for A LOT of time (even in idle!) without flushing it not in 1 second, not in seconds, neither in minutes!
Since as you well documented L2 is lost anyway in case of failure/crash, this behaviour is really dangerous since user could think to have only data for 1 second to be flushed and instead (as in some of my tests...) there are GB & GB of data in L2 still to be flushed...!!!
I don't know if this is a bug or an intended behaviour, BUT anyway, this behaviour is not so well documented and in setup screen too there is nothing indicating that defer write latency has to be intended for L1 only!
I would like to have a support comment on this...
P.S.: obviously I've changed my testing setup with L2 set as read only but I lost some "populating benefit" this way...
EDIT: updated title with recent discoveries... see latest posts of the topic!
at first let me make you my congratulations for this GREAT piece of software!
I'm an IT manager and I found it recently, searching for a product of this type for a particular project I'm setting up. And it fits my needs greatly way!
Because of my engineering formation and having the need of maximum reliability in my "critical" project, I've read ALL the "fuc**d" manual, documentation and FAQs, many posts here and then I have set up a testing system to try all the options, make some sintetic & real world benchmark and fine tuning at best for my needs...
It's during these tests that I found what I think it's a BUG or, at least, a bad documented behaviour that could be very dangerous if not well understood by users.
After many tests I was finally working with this (very good IMHO!) configuration:
- L1 R/W: 3 GB / 1 GB
- L2 R/W: (about...) 650 GB / 100 GB
- Block size: 32 KB
- Strategy: Read & Write
- Defer write: 1 sec
- Mode: Intelligent
- Options: FreeWritten, FlushSleep
- Prefetch: Disabled
- Volatile cache content: enabled
- Free cache on written: enabled
- Flush L1 to L2: disabled
As you can see this is a good performance strategy with an OPEN eye to security of data (volatile cache content, only 1 sec defer write latency, which makes the difference anyway!).
It's during the final tests that I found the BUG (or the not well documented behaviour!): defer write latency is complied *ONLY* by L1 cache, with L2 cache which will retain data for A LOT of time (even in idle!) without flushing it not in 1 second, not in seconds, neither in minutes!
Since as you well documented L2 is lost anyway in case of failure/crash, this behaviour is really dangerous since user could think to have only data for 1 second to be flushed and instead (as in some of my tests...) there are GB & GB of data in L2 still to be flushed...!!!
I don't know if this is a bug or an intended behaviour, BUT anyway, this behaviour is not so well documented and in setup screen too there is nothing indicating that defer write latency has to be intended for L1 only!
I would like to have a support comment on this...
P.S.: obviously I've changed my testing setup with L2 set as read only but I lost some "populating benefit" this way...
EDIT: updated title with recent discoveries... see latest posts of the topic!