Editing Write Anywhere File Layout (section)

===Nonvolatile memory===
[[File:NVRAM-MCC.png|thumb|Non-volatile memory cache mirroring in a MetroCluster and HA]]
Like many competitors, NetApp ONTAP systems utilizing memory as a much faster storage medium for accepting and caching data from hosts and, most importantly, for data optimization before writes which greatly improves the performance of such storage systems. While competitors widely using [[non-volatile random-access memory]] (NVRAM) to preserve data in it during unexpected events like a reboot for both write caching and data optimization, NetApp ONTAP systems using ordinary [[random-access memory]] (RAM) for data optimization and dedicated NVRAM or NVDIMM for logging of initial data in an unchanged state as they came from hosts similarly as transaction logging done in [[Relational database]]s. So in case of disaster, naturally, RAM will be automatically cleared after reboot, and data stored in non-volatile memory in the form of logs called ''NVLOGs'' will survive after reboot and will be used for restore consistency. All changes and optimizations in ONTAP systems done only in RAM, which helps to reduce the size of non-volatile memory for ONTAP systems. After optimizations data from hosts structured in Tetris-like manner, optimized and prepared with passing few stages (i.e., WAFL and RAID) to be written in underlying disks in RAID groups on the [[ONTAP#Aggregates|aggregate]] where data are going to be stored. After optimizations, data is going to be sequentially written on disks as part of the Consistency Point (CP) transaction. Data written to aggregates will contain necessary WAFL metadata and [[NetApp FAS#RAID|RAID]] parity so no additional read from data disks, calculate and write to parity disks operations will occur as with traditional RAID-6 and RAID-4 groups. CP at first creating system snapshot on an aggregate where data are going to be written, then optimized and prepared data from RAM written sequentially as a single transaction to the aggregate, if it fails, the whole transaction fails in case of a sudden reboot which allows WAFL file system always to be consistent. In case of successful CP transaction new active file system point is propagated and corresponding NVLOGs cleared. All data are always going to be written to a new place, and no rewrites can occur. Data blocks deleted by hosts marked as free so they could be used later on next CP cycles and the system will not run out of space with the always-write-new-data-to-new-place policy of WAFL. Only NVLOGs in HA storage systems is replicated synchronously between two controllers for HA storage system failover capability, which helps to reduce overall system memory protection overheads. In a storage system with two controllers in HA configuration or [[NetApp FAS#Metro Cluster|MetroCluster]] with one controller on each site, each of the two controllers divides its own non-volatile memory into two pieces: local and its partner. In MetroCluster configuration with four nodes, each non-volatile memory divided into next pieces: local, local partner's and remote partner's.<ref>{{cite web
 |format       = url
 |publisher    = NetApp
 |access-date  = 24 January 2018
 |date         = 1 September 2015
 |archive-date = 2018-01-24
 |archive-url  = https://web.archive.org/web/20180124192352/https://library.netapp.com/ecmdocs/ECMP12458277/html/GUID-BA431EBE-6C87-44A0-9772-7B460D7D7F6A.html
 |url          = https://library.netapp.com/ecmdocs/ECMP12458277/html/GUID-BA431EBE-6C87-44A0-9772-7B460D7D7F6A.html
 |title        = Clustered Data ONTAP® 8.3. MetroCluster™ Management and Disaster Recovery Guide: NVRAM and NVMEM cache mirroring in a MetroCluster configuration
}}</ref>

Starting with the All-Flash FAS A800 system, NetApp replaced the NVRAM PCI module with NVDIMMs connected to the memory bus, increasing the performance.