Write caching

[Jonathan .]

My server specs:
Dell PowerEdge T320 | FreeNAS-11.3-U4.1
Intel(R) Xeon(R) CPU E5-2450 0 @ 2.10GHz |
32Gb DDR3 (4x8Gb)
120GB WD Green SSD for boot
1Gb broadcom NIC
2x Dell 2TB mirror

My internet at home set up for 1 gigabit internally with 100 down and 10 up all of the large file transfers are internally done form windows, most of the time it has to be over wifi but when I can I use ethernet. I add large folders containing photos every so often and back up devices daily to it, as well as expanding a plex library frequently. For the main file section fo the server I have 2x 2Tb drives mirroring each other would I benefit from adding a write cache and if so what would be the best way going about it?

Thanks in advance

 

[jgreco]

My server specs:
Dell PowerEdge T320 | FreeNAS-11.3-U4.1
Intel(R) Xeon(R) CPU E5-2450 0 @ 2.10GHz |
32Gb DDR3 (4x8Gb)
120GB WD Green SSD for boot
1Gb broadcom NIC
2x Dell 2TB mirror

My internet at home set up for 1 gigabit internally with 100 down and 10 up all of the large file transfers are internally done form windows, most of the time it has to be over wifi but when I can I use ethernet. I add large folders containing photos every so often and back up devices daily to it, as well as expanding a plex library frequently. For the main file section fo the server I have 2x 2Tb drives mirroring each other would I benefit from adding a write cache and if so what would be the best way going about it?

Thanks in advance

What do you mean by "adding a write cache?" You already have a write cache.

 

[c77dk]

FreeNAS/TrueNAS doesn't have a "write cache" as such - writes will be buffered in RAM and then flushed to disks.

You might be thinking of SLOG? but this only helps when you do sync writes (async will always be faster). When you're talking about backups I would hope you want to use sync writes. There's a section in the forums with benchmarks of different SSDs used for SLOG.

With TrueNAS 12 you can make special vdevs, where metadata resides on SSDs, and as such gets faster to access/update, but remember to use redundancy here as well.

The best way to figure out if you need SLOG/special vdevs is to test and see how your disks hold up. On 1Gbps I wouldn't be surprised if you could saturate the link easily, but it all depends on the load patterns.

 

[jgreco]

FreeNAS/TrueNAS doesn't have a "write cache" as such - writes will be buffered in RAM and then flushed to disks.

Well, that's my point, he already has a large write cache and it is fast as hell.

You might be thinking of SLOG? but this only helps when you do sync writes (async will always be faster).

Any use of sync writes will always be slower than async writes, and even there, SLOG isn't any sort of cache. The writes still commit to disk through the transaction group process (your "write cache") but are slowed down so that they are also committed to SLOG, assuring the POSIX write semantics.

https://www.ixsystems.com/community/threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/

 

[Jonathan .]

When you're talking about backups I would hope you want to use sync writes

I have no idea whether it is sync or async for backups and in all honesty, I am not 100% sure what that means for the file backups I just use file history into a sub data set with a size limit enough for 2 full backups before the older one gets replaced if there is a better method I would love to hear thank you for the quick responses already

 

[Jonathan .]

Well, that's my point, he already has a large write cache and it is fast as hell.

So the 32 Gb of ram is more than enough for write cache (just checked and 23Gb is currently being used for it) and adding a SlLOG in my situation wont benefit me?

 

[jgreco]

So the 32 Gb of ram is more than enough for write cache (just checked and 23Gb is currently being used for it) and adding a SlLOG in my situation wont benefit me?

ZFS uses your system memory for write cache. I discuss what's going on in that link above. While the article is slightly dated, the mechanism is still very similar. ZFS is better than it used to be and now tries to "right-size" transaction groups to your pool size, which gives you the best performance possible.

Sync writes are always going to be slower than async writes. It's just a matter of "how much slower." It used to be "50% slower" but these days with Optane and other options it can be "only slightly slower."

But the big question is whether or not sync writes matter to you. There are cases where they're absolutely critical, other cases where some people find them desirable, and also cases where they're a waste of expensive resources. I don't know that backups require sync writes. Many types of backup jobs are ruined if a filer reboots anyways, so my leaning would be towards "it doesn't matter for backups."

 

[Jonathan .]

ZFS uses your system memory for write cache. I discuss what's going on in that link above. While the article is slightly dated, the mechanism is still very similar. ZFS is better than it used to be and now tries to "right-size" transaction groups to your pool size, which gives you the best performance possible.

Sync writes are always going to be slower than async writes. It's just a matter of "how much slower." It used to be "50% slower" but these days with Optane and other options it can be "only slightly slower."

But the big question is whether or not sync writes matter to you. There are cases where they're absolutely critical, other cases where some people find them desirable, and also cases where they're a waste of expensive resources. I don't know that backups require sync writes. Many types of backup jobs are ruined if a filer reboots anyways, so my leaning would be towards "it doesn't matter for backups."

Thank you very much for all of your help. I have one more question that is totally unrelated but the server I got is second hand from my uncles old business and has Windows Server 2016 installed on another drive in it, I am not sure if there would be a situation where I would want, but if I did is there a way stop the FreeNAS and boot up the windows for a bit and if so would I be able to access the drives in the ZFS pool or not and if so how? Thanks again for all of your help

 

[HoneyBadger]

I don't know that backups require sync writes. Many types of backup jobs are ruined if a filer reboots anyways, so my leaning would be towards "it doesn't matter for backups."

I'd agree with this. A "backup" that can't be restored isn't really a backup at all, so run async (for speed) with a separate verification pass (for confirmation) - save sync writes for data where you can't hit "Retry" or "Resume"

I have one more question that is totally unrelated but the server I got is second hand from my uncles old business and has Windows Server 2016 installed on another drive in it, I am not sure if there would be a situation where I would want, but if I did is there a way stop the FreeNAS and boot up the windows for a bit and if so would I be able to access the drives in the ZFS pool or not and if so how? Thanks again for all of your help

Assuming that you do not overwrite the Windows Server drive (I recommend unplugging it entirely) you can still boot from and run that operating system - but you won't be able to access the FreeNAS ZFS pool or files stored there (in any reliable manner.) OpenZFS on Windows is in extremely early stages and I wouldn't rely on it for anything other than a proof-of-concept.

 

[Jonathan .]

Assuming that you do not overwrite the Windows Server drive (I recommend unplugging it entirely)

The drive is ROM attached to one of the add-in cards so I cant but it just does not boot to it and FreeNAS does not pick it up

OpenZFS on Windows is in extremely early stages and I wouldn't rely on it for anything other than a proof-of-concept.

I guess I will have to keep an eye out in the future
Thank you to everyone for all their help it is much appreciated

 

[HoneyBadger]

The drive is ROM attached to one of the add-in cards so I cant but it just does not boot to it and FreeNAS does not pick it up

I'm curious about this, as it suggests that you've got a RAID controller or other piece of hardware that isn't well-liked or well-supported under FreeBSD.

 

[Jonathan .]

I'm curious about this, as it suggests that you've got a RAID controller or other piece of hardware that isn't well-liked or well-supported under FreeBSD

The RAID controller is the Perec H310, running as a passthrough, but I believe that the ROM is located in the NIC reason below:

When the NIC is first in boot order, the server boots up to windows server 2016 the NIC: Broadcom 5720 1Gbps Dual Port Network Card