Hello FreeNas-Forum!

[Deleted member 85691]

Hi there,

just a quick rundown of the Hardware i'm using, it's an older gaming system of mine that has found it's retirement usage as a freenas host.

• AMD FX 6200
• Asus Sabertooth 990FX R2.0
• 16GB Corsair Vengance 1600MhZ non-ecc ram
• BeQuiet 500W PSU
• 4x 500GB HDD's (3x WD, 1x Samsung, old drives from old systems running with the ssd as a cache in raidz2)
• 1x 40GB Intel SSD

I'm using the Plex and Subsonic plugins and i'm attempting to get the HTPC-Manager Plugin working, but thats not really that "mission-critical"

 

[kdragon75]

Sounds like a good system to get your feet wet. I'm curious, how are you using your SSD? Id that your boot drive?

 

[Deleted member 85691]

Sounds like a good system to get your feet wet. I'm curious, how are you using your SSD? Id that your boot drive?

Im using it as a cache drive. The System is booting from a sandisk usb stick.

 

[kdragon75]

So you have it added as a L2ARC drive? You probably dont want that. have you checked you L2ARC hit ratio and your ARC hit ratios under a typical load? for things like media streaming, it will almost never help performance. Please take a moment and read over the ZFS Primer in the official FreeNAS Documentation espesial the section about ZFS provides a read cache (sorry no direct link ;)). To boil some so of the information down, the ARC helps most when working with the save data over and over. When streaming meda you tend to have long slow sequential reads where the primary array is more than fast enough to keep up. When you add the fact that all media streaming clients use a buffer of some size, its even less important to have low laticey fast reads as some (all) of that jitter and latency is (by design) hidden by the streaming send buffer and the clients receive buffer.

Outside of streaming, when working with large files the same general things are at work. Not to mention the L2ARC uses ARC to map to the cached blocks and added more steps and the SSD is WAY slower that the RAM, unless your ACTIVE data is larger than RAM, the l2ARC will slow things down. By active I mean, that's 80% that will ever be accessed on a regular (hourly/daily) basis. Again long slow streaming reads are a bad use case for L2ARC.

Don't take my word for it. do some benchmarking and see if, for your exact case, if it does help.https://forums.freenas.org/index.php?threads/notes-on-performance-benchmarks-and-cache.981/ some info on benchmarking.

 

[Deleted member 85691]

So you have it added as a L2ARC drive? You probably don't want that. have you checked you L2ARC hit ratio and your ARC hit ratios under a typical load? for things like media streaming, it will almost never help performance. Please take a moment and read over the ZFS Primer in the official FreeNAS Documentation espesial the section about ZFS provides a read cache (sorry no direct link ;)). To boil some so of the information down, the ARC helps most when working with the save data over and over. When streaming meda you tend to have long slow sequential reads where the primary array is more than fast enough to keep up. When you add the fact that all media streaming clients use a buffer of some size, its even less important to have low laticey fast reads as some (all) of that jitter and latency is (by design) hidden by the streaming send buffer and the clients receive buffer.

Outside of streaming, when working with large files the same general things are at work. Not to mention the L2ARC uses ARC to map to the cached blocks and added more steps and the SSD is WAY slower that the RAM, unless your ACTIVE data is larger than RAM, the l2ARC will slow things down. By active I mean, that's 80% that will ever be accessed on a regular (hourly/daily) basis. Again long slow streaming reads are a bad use case for L2ARC.

Don't take my word for it. do some benchmarking and see if, for your exact case, if it does help.https://forums.freenas.org/index.php?threads/notes-on-performance-benchmarks-and-cache.981/ some info on benchmarking.

Huh thanks! So i just checked and under Volume Status -> View Volumes it says that the four drives are in a raidz2 and the ssd is found under cache -> stripe right below the raidz2 but still under the volume the raidz2 is in aswell (i hope you can understand what im trying to say :D ) I thought the SSD was a write cache so that when im writing data to the volume the data gets on the ssd first and is then transferred later on the hdd's. But i just transferred about two GB, and while it is transferring the data at 113MB/s stable, when i check with the report tab under freenas, the ssd only got about 400mb written on it, while the hdd's stated about two gb written on them.

Thank you for the hint, i will take a look at it!

 

[kdragon75]

Yeah, that sounds like an L2ARC. The (L2)ARC is a two part cache mechanism. Part is for the most recently accessed data (some of the file you wrote to disk) and the other part is the most frequently accessed data. this allows us to keep the cache "hot" with items that we read all the time but also try caching new items as they are used.

EDIT: All ZFS write go through a TXG it's just async writes that get to hangout there before eventual commiting to disk. Just to clarify.

ZFS has a built in write cache for non-sync or async writes. This is known as the transaction group or TXG for shorthand. The TXG has two ways that it get flushed to disk when working with non-sync writes. The first is a simple time out and the default is set to 5 seconds. The second is a number of bytes. Sync writes are another animal that most people don't need to think about unless your using NFS or virtual machines.

 

[Deleted member 85691]

Yeah, that sounds like an L2ARC. The (L2)ARC is a two part cache mechanism. Part is for the most recently accessed data (some of the file you wrote to disk) and the other part is the most frequently accessed data. this allows us to keep the cache "hot" with items that we read all the time but also try caching new items as they are used.

EDIT: All ZFS write go through a TXG it's just async writes that get to hangout there before eventual commiting to disk. Just to clarify.

ZFS has a built in write cache for non-sync or async writes. This is known as the transaction group or TXG for shorthand. The TXG has two ways that it get flushed to disk when working with non-sync writes. The first is a simple time out and the default is set to 5 seconds. The second is a number of bytes. Sync writes are another animal that most people don't need to think about unless your using NFS or virtual machines.

Alright thank you, i didnt know that! What would you reccomend to do with the ssd then ? As far as i have understood, it isnt hurting the performance in any way, but it isnt helping me either, because i dont have the right usecase scenarios ? The ARC Hit ratio is about 94% while the L2Arc hit ratio is about 0,1%.

 

[kdragon75]

Try removing it, your ARC will have more room and the hit ratio may go up a pinch. Likely not enough to notice especially on 1gb networking. I would use it for the boot drive.