To do this a part of main memory is used for caching data that was either used recently or the data is being accessed most frequently. This means, caching the information that an application would require in the near future, while discarding the ones that will be needed furthest ahead in time. Instead of making sure that we get good performance, as well as reliable transactions, now ZFS’ motive shifts to predicting the future. When trying to cache the read operations, our objective changes. You can set the flag: sync=always to make synchronous writes the default behavior for any given dataset.įor most use cases, the small 16GB to 64GB of really fast and durable flash storage are the most suitable candidates for a SLOG device.Īdaptive Replacement Cache (ARC) and L2ARC Most databases, and applications like NFS, do rely on synchronous writes all the time. So applications which desire consistency over performance can open files in synchronous mode and then the data is only considered to be written once it is actually on the disk. However, the fact remains that in case of system failure or power loss, all the buffered writes in the main memory are lost. This is the default behavior of many operating systems, even when running ZFS. The OS simply stores the data in memory and tells the application, who requested the write, that the write is completed. This is known as asynchronous write and it gives decent performance gains for applications that are fault tolerant or where data loss doesn’t do much damage. ZFS, like most other filesystems, tries to maintain a buffer of write operations in memory and then write it out to the disks instead of directly writing it to the disks.

ARC and L2ARC which are meant for READ operations.

ZFS Intent Log, or ZIL, to buffer WRITE operations.

There are two different caches that a pool can make use of:

About cache device disk