ZFS: 120GB SSD for L2ARC or ZIL?

ultrakomm

n00b
Joined
Jul 25, 2012
Messages
46
Hi!

I'm running a ZFS NAS with a 3x 2TB RAIDZ-1 setup. The machine has 8GB of RAM. I store mostly photos and documents, as well as some bigger files such as some disk images. It also hosts a few virtual machines.

Would I gain anything by using a spare 120GB SSD I have laying around for either L2ARC or ZIL?
 
Data is accessed by clients through both SMB and NFS (and also HTTP). Mainly SMB, though.
 
about L2Arc
you need RAM for L2Arc
with only 8 GB of RAM, skip that and check if you can add RAM.

about ZIL
While you should allow sync write with a VM storage, a slow SSD
can be worser than your onpool ZIL.

I would either use the SSD elsewhere (ex desktop) or buy another
SSD to buld a mirror and use it as a fast storage pool for VMs.
 
Alternatively, if you have good, regular and frequent backups, you could just disable sync...
 
you need RAM for L2Arc
with only 8 GB of RAM, skip that and check if you can add RAM.
Yes, you need RAM for the L2 headers, but the amount only starts becoming significant with small block sizes. A quick look on one of my servers shows that l2_hdr_size is under a 1/1000th of the data in the L2 ARC when using 128k blocks.
 
You can use one SSD for both tasks using partitions. Using a non-protected SSD for sLOG (dedicated ZIL) could be the equivalent of having no ZIL at all. You need an SSD with power-safe capacitors that honours the FLUSH command. That is not Samsung or Sandforce or other consumer-grade drives.

The only consumer-grade SSDs you can use - that i know - are: Intel 320, S3500, S3700, Crucial M500/M550/MX100/MX200.

For L2ARC you can use the most crappy of SSDs since all corruption will be detected by checksums. Loss of data or corruption is no problem for L2ARC. But as stated you also need some RAM to utilise the L2ARC. With few RAM, not all of the L2ARC partition space can be utilised. You can instead consider using the SSD for data storage instead, having a ZFS pool on the SSD to store some of your VM images. That might make a lot more sense depending on your situation.
 
The Crucial "Powerloss Protection" seems to be more a marketing fake

Crucial's power loss protection in client SSDs is not the same as in enterprise drives, but a backup circuitry that merely protects the existing data from corruption. The MX200 brings no changes to that and only offers data-at-rest protection, meaning that the NAND mapping table as well as any in-flight user data are still vulnerable to sudden power losses.

http://www.anandtech.com/show/9258/crucial-mx200-250gb-500gb-1tb-ssd-review
 
Yes i have addressed this with AnandTech editor HellHammer. The same applies to newer Intel SSDs like S3500 and S3700. Only the Intel 320 protects the full write-back which is 256KiB SRAM internally in the chip - the DRAM chip is not used to buffer writes.

Losing the data in DRAM however is not a problem at all. Second generation filesystems (NTFS, Ext3, UFS+SU) have been designed to cope with that with the device write-back buffer being enabled. Harddrives lose the data in DRAM once power is lost, but all writes that have been confirmed with a FLUSH CACHE command, are guaranteed to have survived. The Crucial SSDs basically match this level of protection, whereas Samsung SSDs revert to a state in the past even beyond FLUSH CACHE commands so they do not honour FLUSH commands. This makes them unsuitable as sLOG device.

So i would assert that Crucials protection is not fake at all; none of the material they provided have any errors in them. In fact, it was the assumptions of AnandTech editors themsleves that were at fault, simply assuming that the protection was at the same level of Intel 320 where the entire buffercache was protected. Looking at the tiny capacitors and knowing that Crucial drives use DRAM buffer-cache one can simply conclude that this cannot be the case.

Either way, the Crucial should still be suitable as sLOG while Samsung SSDs are not. That is one key difference. A friend of mine on the Dutch Tweakers.net forum is designing a file-sync test that may provide some evidence to backup this claim.
 
Yes, only relevant item is if data is on the SSD when a write is committed to ZFS even on a powerloss during a write.

Desktop SSDs without powerloss protection are quite senseless for a ZIL if you need the transactional security of sync write.
Remains the question if you really can trust a solution. While this is out of doubt with enterprise Intels like 3500 up or HGST,
I am not sure if I would trust the desktop Crucials without serious tests for a critical part like a ZFS ZIL unless such
professional features are on their prime focus or such features become quite normal even outside the enterprise SSDs.

Remains the question, about the quality of the Anandtech review.
I would prefer a Crucial over any other SSD without a powerloss protection but would prefer enterprise Intels.
 
Yes i have addressed this with AnandTech editor HellHammer. The same applies to newer Intel SSDs like S3500 and S3700. Only the Intel 320 protects the full write-back which is 256KiB SRAM internally in the chip - the DRAM chip is not used to buffer writes.

Losing the data in DRAM however is not a problem at all. Second generation filesystems (NTFS, Ext3, UFS+SU) have been designed to cope with that with the device write-back buffer being enabled. Harddrives lose the data in DRAM once power is lost, but all writes that have been confirmed with a FLUSH CACHE command, are guaranteed to have survived. The Crucial SSDs basically match this level of protection, whereas Samsung SSDs revert to a state in the past even beyond FLUSH CACHE commands so they do not honour FLUSH commands. This makes them unsuitable as sLOG device.

So i would assert that Crucials protection is not fake at all; none of the material they provided have any errors in them. In fact, it was the assumptions of AnandTech editors themsleves that were at fault, simply assuming that the protection was at the same level of Intel 320 where the entire buffercache was protected. Looking at the tiny capacitors and knowing that Crucial drives use DRAM buffer-cache one can simply conclude that this cannot be the case.

Either way, the Crucial should still be suitable as sLOG while Samsung SSDs are not. That is one key difference. A friend of mine on the Dutch Tweakers.net forum is designing a file-sync test that may provide some evidence to backup this claim.

Here we go again, saying Intel S3700, S3500 is the same as crucial is absurd :rolleyes:

I already showed you quotes from INTEL REPS stating what you say is wrong but you still go around spewing your bullshit.
 
And i have responded to those quotes with a response that i believe you have not responded to? The quotes from the Intel representative were ambiguous, stating that Intel S3500/S3700 SSDs would protect writes that 'have been confirmed'. This could refer to writes that have been confirmed by a FLUSH CACHE command; and not writes that have not been 'confirmed' as such, but are asynchronous writes residing in the DRAM buffercache.

If you have more information, then please share. Otherwise, please refrain from personal attacks, thanks!
 
Last edited:
Why does everyone think they need SSD SLOG or L2ARC?

These questions return all the time, even for small systems like the one of the OP.

Spend your money on RAM and Intel server grade network cards. Much more useful.

OR

Get a UPS to protect against power cuts and disable the ZIL completely. No affordable SSD will match a pool running without a ZIL. (Make sure you can do a graceful shutdown and you'll be fine)

OR

Do absolutely nothing 3 good HDD's will saturate 1 Gb/s Ethernet easily. Spend your money on beer.
 
Why does everyone think they need SSD SLOG or L2ARC?

These questions return all the time, even for small systems like the one of the OP.

Spend your money on RAM and Intel server grade network cards. Much more useful.

OR

Get a UPS to protect against power cuts and disable the ZIL completely. No affordable SSD will match a pool running without a ZIL. (Make sure you can do a graceful shutdown and you'll be fine)

OR

Do absolutely nothing 3 good HDD's will saturate 1 Gb/s Ethernet easily. Spend your money on beer.

Well in all fairness OP did mention NFS, which is one of the more clear cut cases for a SLOG. But generally I agree that the need for a SLOG or L2ARC is usually the exception rather than the rule for simple home systems.
 
For a pure media filer, you do not need an L2ARC as it will skip sequential reads per default
and is used for random reads only. And then RAM is a much faster cache than an SSD.

For a pure filer, a ZIL is not used and needed at all (no sync writes).

So yes, you must look at the use case do decide whether it makes sense or not.
An L2ARC can make sense if you cannot add more RAM or if you need a large cache.
A ZIL makes sense if you need the highend features sync write (transactional safe writing).

Both features depend not on the performance of your network as they affect reactiveness on small
random reads and writes. This is where disks are lousy.

As a ZIL adds an additional logging to a regular write, it will always be slower than a write with sync
disabled - even with the fastest ZIL, the DRAM based ZeusRAM. ZIL is not a performance cache
(ZFS will do RAM write caching per default), this is a security mechanism like a BBU on a raidcontroller -
on VMs with older filesystems or databases a nice to have or must have feature.
 
For a pure media filer, you do not need an L2ARC as it will skip sequential reads per default
and is used for random reads only. And then RAM is a much faster cache than an SSD.

For a pure filer, a ZIL is not used and needed at all (no sync writes).

So yes, you must look at the use case do decide whether it makes sense or not.
An L2ARC can make sense if you cannot add more RAM or if you need a large cache.
A ZIL makes sense if you need the highend features sync write (transactional safe writing).

Both features depend not on the performance of your network as they affect reactiveness on small
random reads and writes. This is where disks are lousy.

As a ZIL adds an additional logging to a regular write, it will always be slower than a write with sync
disabled - even with the fastest ZIL, the DRAM based ZeusRAM. ZIL is not a performance cache
(ZFS will do RAM write caching per default), this is a security mechanism like a BBU on a raidcontroller -
on VMs with older filesystems or databases a nice to have or must have feature.

If by ZIL you really meant SLOG then I agree entirely.
 
If by ZIL you really meant SLOG then I agree entirely.

Yes, an Slog is a ZIL on a separate device that you can use to improve performance over
the on-pool ZIL - both is only relevant if you need and use a ZIL with sync write enabled.
 
Don't add either "just because" or because "you've got spare hardware laying around". The setup seems solid so why mess with it? Many would argue that you don't need to think about l2arc until you've got 64GBs of RAM. And while I do believe, yes this would work. Some serious tuning would be advised. Also most common guidelines state that the zil should be mirrored and the l2arc be striped.
 
Last edited:
Back
Top