> From: Thomas Burgess [mailto:wonsl...@gmail.com] > > I might be somewhat confused to how the ZIL > works but i thought the point of the ZIL was to "pretend" a write > actually happened when it may not have actually been flushed to disk > yet...
No. How the ZIL works is like this: Whenever a process issues a sync write, the process blocks until the OS acknowledges the write has been committed to nonvolatile storage. Assuming you have a dedicated log device, the OS immediately commits this data to the log device, and unblocks the process. Then, the data is able to float around in RAM with all the async write requests, getting optimized for disk performance and so forth. The OS might aggregate up to 30 secs of small writes into a single larger sequential transaction for the primary storage devices. If there's an unfortunate event such as system crash during the meantime, then upon the next bootup, the OS will notice data in the ZIL log, which was intended for a TXG, which never made its way out to primary storage. Therefore, the OS replays the log, and commits those writes now. All the async writes that were still in RAM were lost, but the sync writes were not. The dedicated log device helps sync writes approach the performance of async writes. Nothing beats the performance of async writes. If you disable ZIL, then sync writes are handled the same as async writes. Both in terms of performance, and risk. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
