SLOG and SSDs: are "super" capacitors really needed?
cscoman at gmail.com
Thu May 21 15:57:59 UTC 2015
I know I might be off here, but I think it goes like this...
Write transactions are done in memory, the ZIL/SLOG is just the backup
copy. So a write goes into memory, then written to the pool. The purpose of
the ZIL is if a transaction does not complete to disk and the power is
yanked from the machine, it can replay that transaction from the ZIL. The
reason having a fast SLOG device speeds up sync writes is that the SLOG is
better able to keep in sync with RAM vs. when the ZIL is on the slower
spinning disk. So ZFS will not acknowledge the write till the data is in
RAM and secure in the ZIL.
So it is very important to have a SLOG device with a super cap for when
something like the power goes out and the SSD has not completed the write
from its cache to nv storage, you just lost that transaction.
On Thu, May 21, 2015 at 8:38 AM, Chris Stankevitz <chrisstankevitz at gmail.com
> When sync data is written to the ZIL (or in my case to a SLOG), ZFS
> waits for the write to be "completed" before continuing. Once the
> write has "completed", the sync data is considered written, even if it
> has not yet made it to the real storage devices. Written data has
> "completed" when the ZIL device (SLOG) reports that the data has been
> Question: do SSD drives report the write has "completed" only after
> the data has been burned into non-volatile storage? If so, then why
> do people say a good SLOG SSD has "super capacitors" that allow the
> drive to continue functioning for a short time after a power failure?
> It seems to me that there are two scenarios, none of which need super
> 1. A transaction is completely written to the SLOG, but not the
> storage devices, and the power goes out. No problem, data will write
> to storage when the pool is imported.
> 2. A transaction is partially written to the SLOG, but not the storage
> devices, and the power goes out. No problem, the transaction will be
> lost and the pool will be imported with the previously committed
> I don't see a scenario where a power-outage causes a "corrupted
> transaction" to be posted.
> Now if an SSD reports data "written" before it makes it to
> non-volatile storage, then that is another story... but I cannot
> imagine a HDD manufacturer advertising data written that is not
> actually written (or guaranteed to be written even in the face of a
> power outage).
> Thank you,
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions