When to implement a SLOG

[lanlubber]

I decided to start a new post instead of adding to my previous that jgreco was really helpful in. I've read through as many ZIL, SLOG posts as I can but I'm hitting a point of diminishing returns. I'm going to be storing VMs for my ESXi server on a mirror set (separate from my RAIDZ2 NAS pool) so I'll have synchronous write requests hitting the mirror set. I'll probably have maybe 2-3 VMs running at any given time, mostly idle since this is for home use. Is a ZIL created per pool (volume)? So one on my NAS pool (RAIDZ2) and one on my mirror set or do the pools share a single ZIL?

Thanks

Edit: the title ended up being a little different than my question, but depending on the answer it may be relevant....

 

[m0nkey_]

Is a ZIL created per pool (volume)?

Yes, one SLOG device per pool.

So one on my NAS pool (RAIDZ2) and one on my mirror set or do the pools share a single ZIL?

To answer your question, pools do not share a ZIL. I also think you're confusing terminology. The ZIL is stored on the ZFS pool vdevs. The SLOG is a 'Separate intent LOG', such as an SSD and is attached to the pool. You've probably already read @jgreco's post at https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/ which explains it a whole lot better than I can.

 

[lanlubber]

Thanks for the reply, I did read that post and a few others which were really good. So I guess this is where my post title applies. Since each of my pools (RAIDZ2 & Mirror) will each have their own ZIL do I need to add an SSD SLOG device? If you share a pool between VMs and other data the synch writes can kill the performance overall, but since I have them separated would I really need an SSD SLOG? Keep in mind this is home use and maybe 2-3 running VMs. Thanks

 

[jgreco]

If it is home use and you can cope with the concept of "My NAS crashed and screwed up my VM disks in the process and now I have to fix them or even reinstall" then you're fine to do without sync writes. It isn't horribly different than a single hard drive developing a run of bad blocks or something like that.

If you're a business and you are processing credit card, database, or other transactional data, and would find the loss of data on a VM to be intolerable, and you'd normally protect a physical server with RAID5 or whatever in order to guard against the bad, then you really do need sync writes and failing to get a decent SLOG would be idiotic.

 

[lanlubber]

Thanks again, I guess where I'm struggling a bit is how well is a separate SLOG really protecting us against a system crash of the NAS? It sounds like by implementing an SSD based SLOG for ZIL we're getting the contents of memory written to disk faster than they would have if written to a ZIL on a spinning disk. So what we've done is reduced the exposure window that data could possibly still be queued up in memory that the ESX server has been told (lied to) is committed to disk in the event of a NAS crash. Which is probably sufficient protection for a low utilization environment since that window would be pretty small. So if you have a higher utilization environment with a steady stream of synch writes it's still very possible in the event of a system crash that your VMs could be corrupt if not all data has been committed from memory in time. In which case it seems only a battery backed cache controller could better mitigate this risk. BTW I'm still waiting for all my parts to come in and as I'm going along I'm mocking up my build in a VM. Thanks

 

[jgreco]

So what we've done is reduced the exposure window that data could possibly still be queued up in memory that the ESX server has been told (lied to) is committed to disk in the event of a NAS crash.

There is no such window. That's the whole point of the sync write process. POSIX says that data committed via a sync write must be committed to stable storage, so that a later retrieval will return that data. It doesn't give a crap *how* the guarantee is implemented, which is why things like battery backed caches are acceptable (even though the battery will eventually fail). A battery backed write cache is therefore a not-very-good implementation. ZFS with a power loss protected SSD for SLOG is much better in that the data will actually be written to stable storage in the form of nonvolatile flash memory, which is in fact true stable storage. ZFS with its default in-pool ZIL will also provide the same protection, though it will naturally be a whole lot slower. The only time ZFS won't handle sync data with due care is if you design your pool stupidly (i.e. a non-power-loss-protected SSD) or if you disable sync writes. Both of those are explicit administrator decisions.

So if you have a higher utilization environment with a steady stream of synch writes it's still very possible in the event of a system crash that your VMs could be corrupt if not all data has been committed from memory in time. In which case it seems only a battery backed cache controller could better mitigate this risk.

Wrong, and hell no, in that order.

 

[depasseg]

It sounds like by implementing an SSD based SLOG for ZIL we're getting the contents of memory written to disk faster than they would have if written to a ZIL on a spinning disk. So what we've done is reduced the exposure window that data could possibly still be queued up in memory that the ESX server has been told (lied to) is committed to disk in the event of a NAS crash.

The first sentence is true, the second is not (as clarified by jgreco). ESX won't be lied to if you have sync writes. Whether the ZIL is written to SLOG or the pool, the data will be written. In the case of an SSD SLOG, separate power protection within the device is required to prevent data corruption. And the reason for the SSD SLOG is to reduce latency for the sync acknowledgement.

Sync writes are both queued in RAM and written to the stable storage (either the pool or a SLOG). Under normal ops, data from the ZIL in RAM is written to disk. If the power is lost and during reboot the pool sees pending transactions from the ZIL (whether in pool or SLOG), those transaction get committed to the pool. In the case of using a SLOG, that is the only time data is ever read from the SLOG.

 

[lanlubber]

Thanks all for the help.

OK, I got the "lied to" from the post below which maybe I misinterpreted:

https://forums.freenas.org/index.ph...ror-your-slog-zil-drive-recommendation.23445/

In any case going forward with my test FreeNAS VM, I added two new virtual disks which I intended to mirror and under provision so I can configure a SLOG for my ZIL to avoid too large of a ZIL. I understand in VMWare I could just create small enough virtual disk but I'm trying to simulate what I'll be doing in my real build. It looks like from within the GUI it's an all space or none for creating a mirror set with these disks, no option to under provision. I found a post detailing how to identify my disks from the command line which I did (ada8 and ada9). The post also says under provisioning has to be done from the command line using gpart. Putting the mirror aside for a minute I just tried to use gpart to under provision one of my disks and it tells me no such geom: ada8. I ran "gpart add -t freebsd-zfs -l slog1 -s 2G -b 1M ada8" I can see ada8 from doing "camcontrol devlist" and I see it in my dmesg.boot, and it shows up in the FreeNAS GUI. Any ideas? Thanks again

 

[depasseg]

I underprovisioned using camcontrol which was very straightforward. I'm not sure if it will work on a virtual disk though. And I wouldn't really worry about it in a VM, since the performance isn't representative.

 

[jgreco]

Thanks all for the help.

OK, I got the "lied to" from the post below which maybe I misinterpreted:

https://forums.freenas.org/index.ph...ror-your-slog-zil-drive-recommendation.23445/

You misinterpreted, and you probably shouldn't be dredging up years-old posts anyways. The things we've got as stickies are high-confidence posts. That post, it was talking about the need to mirror SLOG, which is no longer a requirement.

It looks like from within the GUI it's an all space or none for creating a mirror set with these disks, no option to under provision.

I tried to argue for an option to underprovision SLOG devices several years ago, and got shot down because I couldn't "prove" it. Under stress, having a larger pool of free pages is likely to result in being able to sustain high sync write speeds for a longer period of time. There doesn't seem to be a downside to underprovisioning unless you go "too small."

 

[lanlubber]

I underprovisioned using camcontrol which was very straightforward. I'm not sure if it will work on a virtual disk though. And I wouldn't really worry about it in a VM, since the performance isn't representative.

Thanks, the VM environment is just for prototyping my install which will be on physical hardware.

Has anyone used one of these for their SLOG? It looks like it hits the mark, SLC, SATA III, SMART
http://www.ebay.com/itm/SATA-DOM-4G...293525?hash=item3abc012015:g:tUkAAOSwGotWppv1

 

[depasseg]

There isn't built-in power protection and it's likely too small.

 

[jgreco]

And too expensive per GB.