ZIL SLOG Device

R

Ripley

Limp Gawd
Joined
Nov 4, 2004
Messages
240
Would this make a good SLOG?

http://www.newegg.com/Product/Product.aspx?Item=N82E16820167143

I recently saw a recommendation for the Intel S3700 (http://www.newegg.com/Product/Product.aspx?Item=N82E16820167139) as a good SLOG. But I happen to have an extra 32GB Intel 525. I will need to find an adapter to put it in my system but those look affordable. And its stats look better than the S3700.

A couple related questions:

1.) Its my understanding that you can add a SLOG to an already existing pool, is that correct?
2.) Is it recommended to run 2 drives in a mirror for fault tolerance?
3.) What happens to your pool if the SLOG drive(s) fail?
 
afaik Intel 525 lacks powerloss protection, an important feature for a ZIL.
Intel 3700 is perfect

1. yes
2. only if you want to be prepared for a ZIL failure + a powerloss
(or want to avoid the performance degration)
3. The onpool-ZIL is used (performance degration)
 
_Gea said:
afaik Intel 525 lacks powerloss protection, an important feature for a ZIL.
Intel 3700 is perfect

1. yes
2. only if you want to be prepared for a ZIL failure + a powerloss
(or want to avoid the performance degration)
3. The onpool-ZIL is used (performance degration)
Click to expand...

Why is power loss protection an important feature for an SSD?
 
Not for an ssd per se, but for an slog device. Keep in mind this is a transaction log, not a write cache. So a caller does a sync write and zfs commits it to fast storage, then ACKs it to the client. When the write is complete to the pool itself, the entry in the SLOG is deleted. So you are promising that the write has been committed to stable storage. But if a power fail occurs between the write to the SLOG and final write to stable storage, some or all of the data may not have made it there, but the user was told it was. Silent corruption... Normally, the server would come back up, the pool would be imported, zfs would see data in the SLOG and replay those transactions, so you would be okay.
 
danswartz said:
Not for an ssd per se, but for an slog device. Keep in mind this is a transaction log, not a write cache. So a caller does a sync write and zfs commits it to fast storage, then ACKs it to the client. When the write is complete to the pool itself, the entry in the SLOG is deleted. So you are promising that the write has been committed to stable storage. But if a power fail occurs between the write to the SLOG and final write to stable storage, some or all of the data may not have made it there, but the user was told it was. Silent corruption... Normally, the server would come back up, the pool would be imported, zfs would see data in the SLOG and replay those transactions, so you would be okay.
Click to expand...

Is the concern that the SSD is going to lose data in the event of a power loss? And you say normally the server would come back up and you'd be ok. Is that normally with a system that has an SSD SLOG with power loss protection?
 
this is specific to zfs. like i said, it's a transaction log, so you CANNOT tell a client 'i wrote that to stable storage' when you haven't. if you write to the SLOG and tell the client you have committed the data, but it evaporates on a power failure, you have violated consistency constraints. normally, filesystems can handle power loss, because they do device cache flushes at critical times - you might lose data but not (usually) get corruption. in the SLOG case, you might have a filesystem critical operation that was told 'your data went to disk!', but it is actually on the non-protected SSD.
 
The reason you add an SSD to a ZFS pool instead of disabling syncs is basically power loss protection. The pool would be faster if you just deactivate syncs, but the in case of a power loss every write that is currently queued for commit is lost even if the client thinks its data is safe. The SLOG is only read after a power loss, normally it is just written to.

If you do not care about power-loss protection just disable sync writes. The damage would probably be greater compared to a pool with sync writes and an unsafe SLOG, but the magnitude of the loss depends on the write pattern and type of your data.

The general problem is however not specific to ZFS. A consumer SSD can suffer from data loss in case of a sudden power interruption.
 
Last edited:
It depends on the purpose of the storage. If (like many) you are using zfs to serve up storage to VM clients, it IS specific to zfs, since (as I said), serious filesystem corruption can occur on the client due to a disk cache flush not having been done, when the client thought it was. This may or may not be a use case that affects you. In the general scenario, where it is just 'storage', data can be lost, sure, but that would happen even if the ssd had power loss protection, since you almost certainly won't get the data committed to the spinning disk(s) before power was totally lost.
 
That was not specifically meant as a comment to you but to the topic in general. I don't think that there is a point where we disagree. If you add an SLOG to a pool (which sole purpose is to provide a fast non-volatile storage for sync writes that is still as safe as the pool vdevs) you should use one that actually writes the stuff that you write to it.

If you put the ZFS pool itself on SSDs without power-loss protection you may also suffer from corruption, not only on the data, but also the ZFS filesystem itself. By the way, I think that a lot of consumer harddrives lie about sync writes the same way SSDs do just to be better at benchmarks.
 
You must log in or register to reply here.
Back
Top