Some ZIL questions

[Fish]

I'm looking into adding a ZIL to my build since I have non-ECC memory (Yes, I know the risks but I'm a broke college student so there's nothing I can do about it). I've been reading that you really should have your ZIL have some special characteristics, but I don't quite understand them. Does it need to be faster than say 7200RPM? Or is there really not much data throughput needed.

I've got a 2.5" Seagate Momentus 7200rpm 320Gb and 2x Seagate Barracuda 7200rpm 250Gb lying around. Would it benefit me to use 2 mirrored drives?


Thanks in advance for the help.
-fish

 

[jgreco]

If you already have a pool, you already have a ZIL.

https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/

 

[depasseg]

As mentioned, if you are using ZFS (and if you are on FN 9.3, then you are), then you have a ZIL. I think you meant a SLOG. SLOG is only really beneficial for sync writes. I'm not sure how it could help reduce the risks introduced with the use of non-ECC RAM.

 

[Fish]

If you already have a pool, you already have a ZIL.

https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/

That was the article that I was reading, but I must have misunderstood it.

As mentioned, if you are using ZFS (and if you are on FN 9.3, then you are), then you have a ZIL. I think you meant a SLOG. SLOG is only really beneficial for sync writes. I'm not sure how it could help reduce the risks introduced with the use of non-ECC RAM.

So there's a difference between sync writes and just data being written to the pool? I assumed that the SLOG keeps a record of what's going to be written and what was actually written. I guess my real question is this: Is there much I can do to reduce the risk of the non-ECC ram biting me in the ass?

 

[depasseg]

Think of it this way, data to be written to disk gets queued up in RAM, when it gets big enough or enough time has elapsed (5 seconds), it is flushed and written to disk. If you are doing sync writes, the data must be written to disk to acknowledge the sync request (it can't sit in system RAM for 5 seconds), and this is where the SLOG comes in. The SLOG can sit in between RAM and the pool to accommodate the write request and acknowledge the write in parallel to writing to disk. And the SLOG should be battery backed up (or use capacitors), so in case there is a power failure, the SLOG will retain the data that was lost in RAM. At boot it can be checked and the last transaction can be properly flushed to disk. IOW all sync writes are written to the SLOG (and Pool), but data is only ever read from the SLOG in case of a power failure and the last 5-10 seconds of sync-write data needs to be properly written to the pool.

You have 2 choices to reduce the risk of using non-ECC RAM:
1. Don't read or write any data unless absolutely necessary
2. Nevermind, I guess there is only 1 way, and even that really isn't a choice.

 

[Fish]

Think of it this way, data to be written to disk gets queued up in RAM, when it gets big enough or enough time has elapsed (5 seconds), it is flushed and written to disk. If you are doing sync writes, the data must be written to disk to acknowledge the sync request (it can't sit in system RAM for 5 seconds), and this is where the SLOG comes in. The SLOG can sit in between RAM and the pool to accommodate the write request and acknowledge the write in parallel to writing to disk. And the SLOG should be battery backed up (or use capacitors), so in case there is a power failure, the SLOG will retain the data that was lost in RAM. At boot it can be checked and the last transaction can be properly flushed to disk. IOW all sync writes are written to the SLOG (and Pool), but data is only ever read from the SLOG in case of a power failure and the last 5-10 seconds of sync-write data needs to be properly written to the pool.

You have 2 choices to reduce the risk of using non-ECC RAM:
1. Don't read or write any data unless absolutely necessary
2. Nevermind, I guess there is only 1 way, and even that really isn't a choice.

Thanks for all the great info. I would be more concerned about my data becoming corrupted, but I have Crashplan so I'll have it all backed up to the cloud anyway. I'd much rather spend the time re-downloading my data than paying crazy amounts of money for enterprise-level hardware.

 

[depasseg]

Look up the Lenovo TS140 in these forums. "Enterprise Grade" for less than $400.

Please keep in mind that if you are backing up your FreeNAS data to Crashplan, your backed up files are still susceptible to file corruption (I guess no more so than them residing on your desktop though).

 

[jgreco]

Screw the crazy amounts of money for enterprise-level hardware. Just get some decent Supermicro stuff. I've shown repeatedly in the past that it's actually less expensive to do that than it is to get a lot of the prosumer/gamer grade crap put out by all the usual suspects.

 

[Ericloewe]

Screw the crazy amounts of money for enterprise-level hardware. Just get some decent Supermicro stuff. I've shown repeatedly in the past that it's actually less expensive to do that than it is to get a lot of the prosumer/gamer grade crap put out by all the usual suspects.

Hell yeah. My X10SLM+-F was actually cheaper than the cheapest Asus motherboard of the time (when I built the old WHS 2011 server) that had an Intel NIC. P8Z68-V Pro or something of the sort. An X10SLL-F would've been even cheaper.

 

[jgreco]

<frustration-mode>

/aside-to- @Ericloewe ... of course the problem is that when they say "enterprise-level" they mean anything more expensive than the cheapest bit of frickin' generic Shenzhen garbage they can find on amazon

</frustration-mode>

 

[Fish]

Look up the Lenovo TS140 in these forums. "Enterprise Grade" for less than $400.

Please keep in mind that if you are backing up your FreeNAS data to Crashplan, your backed up files are still susceptible to file corruption (I guess no more so than them residing on your desktop though).

CrashPlan does unlimited version-ing as well. 85% of the files will be media such as tv shows and movies which never change.

 

[depasseg]

CrashPlan does unlimited version-ing as well. 85% of the files will be media such as tv shows and movies which never change.

Unless they are corrupt. And that's the problem. You won't know when they change, and you'll have tons of crashplan backups to search through. And hopefully you can find a version that wasn't corrupted. Ask me how I know much of a pain that is. Ask me about the photo of my wife holding my son for the first time that is half gray because part of the file is corrupt. And unfortunately it was like that for over the year of backups that I had on crashplan.