Does a SLOG only work when sync=always?

Scampicfx

Contributor
Joined
Jul 4, 2016
Messages
125
As the title says:

I am replanning some zvols. When I remember correctly, a slog will only be useful when sync=always on the affected zvol.
As long as sync=standard, there will be no benefit from using a slog, correct?

Thank you guys!
 

HoneyBadger

actually does care
Administrator
Moderator
iXsystems
Joined
Feb 6, 2014
Messages
5,110
With sync=standard will only benefit if the client/OS mounting the zvol specifically requests sync writes - but many clients either don't request them or assume that the device providing the LUN has non-volatile write cache.

sync=standard is a good way to force the issue, and can be set/unset on a live zvol; you don't need to recreate just to change that setting.
 

Chris Moore

Hall of Famer
Joined
May 2, 2015
Messages
10,080
What kind of use ?
 

Scampicfx

Contributor
Joined
Jul 4, 2016
Messages
125
Hey,
thanks for your answers. All of my zvols are mounted via iscsi by an esxi hypervisor. I guess that esxi does not force sync writes and in this case sync=standard does not use SLOG?
 

Chris Moore

Hall of Famer
Joined
May 2, 2015
Messages
10,080
Hey,
thanks for your answers. All of my zvols are mounted via iscsi by an esxi hypervisor. I guess that esxi does not force sync writes and in this case sync=standard does not use SLOG?
If you are using iSCSI, you should use SLOG, so you should set sync=always. At least, that is how I remember it. You will also need a fast and durable SLOG device.

There are some links about this in the "Useful Links" in my signature.
 

HoneyBadger

actually does care
Administrator
Moderator
iXsystems
Joined
Feb 6, 2014
Messages
5,110
If you are using iSCSI, you should use SLOG, so you should set sync=always. At least, that is how I remember it. You will also need a fast and durable SLOG device.

Correct. vSphere/ESXi does not request sync writes from iSCSI volumes as it expects that the disk array will provide a non-volatile write cache. Setting sync=always will be necessary to ensure data integrity for in-flight writes.

@Scampicfx what is the make and model of the SSD you are planning to use for an SLOG device? There is a link in my signature (and also in Chris's useful links resource) to an SLOG benchmarking thread; you can look there for some good examples of devices that work well and the level of performance you can expect.
 

Scampicfx

Contributor
Joined
Jul 4, 2016
Messages
125
Hey guys,
thanks for your answers. Right now there are 2 storage pools on this server.
Both storage pools offer iscsi zvols to esxi.

One storage pool is for production and is therefore sync=always
The other storage pool is non-production and is therefore sync=standard

The production storage pool has Intel P3700 PCI-E SSD as slog device.

I am thinking of converging both storage pools to one storage pool. But before doing this, one of the first questions I ask myself is:

What setup does have more performance?
- 1.) iscsi zvol with sync=standard and no slog or
- 2.) iscsi zvol with sync=always and P3700 slog?

I think I remember a guide somewhere in the web claiming the best performance can be achieved by sync=standard (better than sync=always with (!) slog). I'm not sure if that's true - what's your opinion about that? The point is, in case the highest possible performance can be achieved with sync=standard and no slog, it will make no sense to combine these two storage pools! The non-production storage pool needs highest possible performance.

For better understanding, I also want to know if...
- 3.) iscsi zvol with sync=standard AND
- 4.) iscsi zvol with sync=standard and P3700 slog

do have the same performance in case iscsi and esxi as hypervisor are used?

Hey cool, @HoneyBadger! I'm just reading your guide. One of the most important phrases in there to me was:
Only sync writes will actually go to an SLOG.
So when I see it correctly, 3.) and 4.) should have same performance? What's about 1.) and 2.)?

Thanks for all your help!
 

HoneyBadger

actually does care
Administrator
Moderator
iXsystems
Joined
Feb 6, 2014
Messages
5,110
Let's back up a little bit here.

The decision between sync and async is about safety of your writes. If you write async (in the case of ESXi on iSCSI, this is with sync=standard) then a portion of what your VMs and ESXi believe is on stable storage (and can survive your ZFS system crashing or losing power) is unprotected in the ZFS system's RAM. This obviously is the fastest possible solution (because you're just writing to RAM) but that speed comes at the cost of safety.

To enable safety, you force all writes to the zvol to be treated as sync writes by ZFS, using sync=always. The consequence of that is that your pending writes also have to be located on what ZFS considers stable storage. In effect, you've now reduced your writes to the speed of your individual disks comprising the pool. If they're SSDs, this may not be too bad - but for spinning disks, this will be brutally slow.

To accelerate this, ZFS has the idea of a separate log device - or shortened out, an SLOG. Now, instead of writing to "RAM + slow disks" you're writing to "RAM + a fast SSD" - this is significantly faster, but not as fast as just writing to "RAM only."

So to sum it up - Options 1+3+4 will all be incredibly (and equally) fast, but unsafe. If your FreeNAS system loses power/hangs up, you are going to lose any data that VMware "thinks is safe" but ZFS hasn't had a chance to commit to disk. Consequences could rang from "we lost five seconds of work in that VM, better redo it" to "the VM was running a database that's corrupted now, restore from backup" up to "there were critical VMFS metadata operations happening, the datastore is unmountable now." Snapshots and backups can mitigate this risk but they can never totally eliminate it. Only you can answer how valuable those few seconds/MB of data really are.

Option 2, on the other hand, will be as fast as your P3700 (which is pretty quick) but will also be safe. Yes, you may not be able to saturate your 10Gbps line with burst writes. But if the HBA backing your disks decides to let the Magic Blue Smoke out, you can power off the system, replace it, restart, and your pool will import and play back the pending transactions that are safely stored on the P3700.

(Unless the P3700 dies at the same time - but if that's a point of concern, you run two and mirror the SLOG devices.)
 
Top