Sebastian Goetze wrote:
I usually describe NVRAM as a transaction log...
Being really really picky now [sorry]... is it..?
The NVRAM holds a meticulously designed copy (super high integrity) of the transaction log for WAFL, while at the same time limiting the size of the transaction log which is in effect in RAM in the controller.
So saying to ppl that the NVRAM actually *is* the transaction log, is not strictly correct either. Which is why I personally prefer not to say that. Frankly avoiding to mention the NVRAM at all (including the size of it) is the best thing most often, and then when ppl (happens quite often) say things like: "ha ha, a NetApp has sooo little write cache EMC VNX is much better" then you take out the big arsenal and teach them... ;-)
It is true that the speed of the Flash based NVRAM isn't zero effect on things inside ONTAP when writing to disk. But it's small, very small. Tiny, insignificant compared to other factors.
It's also true that the size of the transaction log, as limited by the size of the NVRAM, can affect things w.r.t. performance in various ways. It's good to a certain extent to have a bigger transaction log, but the bigger the NVRAM the worse it gets in a HA failover situation. It slows things down, that's the trade-off. There's no problem per se to make the NVRAM (= the WAFL log) much bigger, the HW guys at NetApp could easily do that but the SW teams responsible for the HA cluster won't allow it, that's basically how it plays out
Cheers, /M
On 1/20/2014 11:33 PM, Jeff Mohler wrote:
PS: I think we just agreed. :)
But its good to make the hard point, that NVRAM is not part of a write. Its common to see it as such, but it's systemically more correct to never mention NVRAM when talking about writes..cuz it doesnt matter. Its just a protection.