Recommendation SSD (cache drive)


Recommended Posts

Hi,

 

I have a Samsung 840 Pro 256GB as cache drive, but it's way to small. I like to know whats SSD you use/recommend also the size. Do you use just one SSD or a RAID 0/1 solution? Other things to think of?

 

It happend again my SSD was totally full and a few Dockers crashed...

Edited by MvL
Link to comment

my few cents; I have used a 750 EVO but the NAND is not durable. Currently I use a CRUCIAL MX500 1TB and it seems excellent price/performance ratio wise (paid ~260 USD). it tends to overheat (probably my bad -airflow since its stuck on the backside of the board against a tower wall) It also feels a bit slower than a Samsung Pro. I´d stick with Samsungs PRO line either SATA or if you need the speed NVMe via PCIe. The PRO line has a higher TBW spec but costs a bit more than the EVO. About size - totally up to you - I had the 750 EVO with 500 and it got too small quickly with all the VMs on it. 

Edited by unrateable
  • Upvote 1
Link to comment

Before my posting I considered a 1TB model, because like you said a SSD is very quickly to small. So you don't advice a EVO. I already thought that EVO's are not suitable for server purposes so good that you can confirm. Thanks for the confirmations!

Link to comment
  • 3 weeks later...

I've been using these since late 2015:

https://www.amazon.com/gp/product/B00M8ABHVQ/

 

I have had zero problems with them and they haven't been used lightly. My cache array runs eleven dockers and two VMs. One VM is a security camera server. 16 4k cameras are writing to the cache array 24/7 (not motion triggered but 16 24/7 4k h.265 streams). On top of that the cache drive is still used for storage array writes (mover runs nightly). They also survived a 140F temps when a fan failed.

 

They aren't the fastest but they just freaking work.

  • Like 1
Link to comment
Quote

I have had zero problems with them and they haven't been used lightly. My cache array runs eleven dockers and two VMs. One VM is a security camera server. 16 4k cameras are writing to the cache array 24/7 (not motion triggered but 16 24/7 4k h.265 streams). On top of that the cache drive is still used for storage array writes (mover runs nightly). They also survived a 140F temps when a fan failed.

 

 

Interesting! 

 

Can you post the S.M.A.R.T values of the SSD?

Edited by MvL
Link to comment
On 4/20/2018 at 1:10 PM, MvL said:

256GB as cache drive, but it's way to small

 

You might reconsider how you use cache. There is no requirement to cache user share writes. Most of the writes to my server are unattended - scheduled backups or queued downloads - and I am not waiting for them to complete anyway. So those user shares aren't cached, don't use up space on cache, don't have to be moved later, and are immediately protected by parity.

 

Link to comment
2 hours ago, trurl said:

 

You might reconsider how you use cache. There is no requirement to cache user share writes. Most of the writes to my server are unattended - scheduled backups or queued downloads - and I am not waiting for them to complete anyway. So those user shares aren't cached, don't use up space on cache, don't have to be moved later, and are immediately protected by parity.

 

 

Yeah, true. Only it's still not enough. If I have a couple of season of a tv show and a UHD rip the SSD is full.

 

1 hour ago, doubleohwhatever said:

Sure. I've attached two of them. I *think* these are the two oldest drives.

SanDisk_SDSSDHII960G_151740411432-20180507-0825.txt

SanDisk_SDSSDHII960G_151855401818-20180507-0823.txt

 

Thanks. I'll check them!

Link to comment

The problem with direct writes (for /me/) is that it causes disks to spin up a lot.  In the evening during the TV season I'll get 2-5+ episodes a night, spinning up the drives in a staggered way for each one is pointless when I can cache them and then move them at once.

 

For the Movies share, it would make sense to do that as those tend to be larger and less frequent additions.

 

ie: it is a balance, usage management combined with cache size :).

  • Like 1
Link to comment
4 hours ago, trurl said:

 

You might reconsider how you use cache. There is no requirement to cache user share writes. Most of the writes to my server are unattended - scheduled backups or queued downloads - and I am not waiting for them to complete anyway. So those user shares aren't cached, don't use up space on cache, don't have to be moved later, and are immediately protected by parity.

 

 

1 hour ago, Tybio said:

The problem with direct writes (for /me/) is that it causes disks to spin up a lot.  In the evening during the TV season I'll get 2-5+ episodes a night, spinning up the drives in a staggered way for each one is pointless when I can cache them and then move them at once.

 

For the Movies share, it would make sense to do that as those tend to be larger and less frequent additions.

 

ie: it is a balance, usage management combined with cache size :).

 

Yeah, good one! Maybe it's better to just cache the tv shows and not the movies or other stuff. Then I'll can use it a little longer. At the moment I'll rather prefer to spend my money on a new rack (open or closed) then a couple of SSD's. Then I'll can buy the SSD's 3 -6 months later...

Edited by MvL
Link to comment
SMART Attributes Data Structure revision number: 4
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   -O--CK   100   100   ---    -    0
  9 Power_On_Hours          -O--CK   253   100   ---    -    19292
 12 Power_Cycle_Count       -O--CK   100   100   ---    -    31
165 Total_Write/Erase_Count -O--CK   100   100   ---    -    4321327194145
166 Min_W/E_Cycle           -O--CK   100   100   ---    -    293
167 Min_Bad_Block/Die       -O--CK   100   100   ---    -    20
168 Maximum_Erase_Cycle     -O--CK   100   100   ---    -    382
169 Total_Bad_Block         -O--CK   100   100   ---    -    0
171 Program_Fail_Count      -O--CK   100   100   ---    -    0
172 Erase_Fail_Count        -O--CK   100   100   ---    -    0
173 Avg_Write/Erase_Count   -O--CK   100   100   ---    -    334
174 Unexpect_Power_Loss_Ct  -O--CK   100   100   ---    -    11
187 Reported_Uncorrect      -O--CK   100   100   ---    -    0
194 Temperature_Celsius     -O---K   049   055   ---    -    51 (Min/Max 11/55)
199 SATA_CRC_Error          -O--CK   100   100   ---    -    0
230 Perc_Write/Erase_Count  -O--CK   100   100   ---    -    14595092066119
232 Perc_Avail_Resrvd_Space PO--CK   100   100   004    -    100
233 Total_NAND_Writes_GiB   -O--CK   100   100   ---    -    310422
234 Perc_Write/Erase_Ct_BC  -O--CK   100   100   ---    -    348690
241 Total_Writes_GiB        ----CK   253   253   ---    -    138826
242 Total_Reads_GiB         ----CK   253   253   ---    -    57432
244 Thermal_Throttle        -O--CK   000   100   ---    -    0
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

 

19292 hours on that is more as 800 days. So 2 years and 2 months used.

0 reallocated sectors nice!

138826GiB writes  that is 138TB ?

 

btw this SSD has TLC memory.

Edited by MvL
Link to comment
4 hours ago, doubleohwhatever said:

Sure. I've attached two of them. I *think* these are the two oldest drives.

SanDisk_SDSSDHII960G_151740411432-20180507-0825.txt

SanDisk_SDSSDHII960G_151855401818-20180507-0823.txt

The drives have consumed 47% of expected wear lifetime.

 

The drives have accumulated about 130+ TB of file system writes and 310+ TB of raw flash writes.

Since they are 1 TB large, that means about 310 writes / memory cell.

 

Edited by pwm
Link to comment
Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x01  =====  =               =  ===  == General Statistics (rev 2) ==
0x01  0x008  4              31  ---  Lifetime Power-On Resets
0x01  0x018  6   3123168738799  ---  Logical Sectors Written !!!!!!!!!!!!!!!!!!!!!!
0x01  0x020  6       976967253  ---  Number of Write Commands
0x01  0x028  6    953863139911  ---  Logical Sectors Read
0x01  0x030  6       265474636  ---  Number of Read Commands
0x07  =====  =               =  ===  == Solid State Device Statistics (rev 1) ==
0x07  0x008  1              47  ---  Percentage Used Endurance Indicator !!!!!!!!!!!!!!!!!!!!!!
                                |||_ C monitored condition met
                                ||__ D supports DSN
                                |___ N normalized value

Missed that part. Interesting!

Edited by MvL
Link to comment

The evil thing here is that the normal SMART numbers doesn't indicate the wear level.

 

Total_NAND_Writes_GiB could have been given the value 53 out of 100 to indicate the wear level. The majority of SMART software doesn't look at all the extra information.

Link to comment

So you can use the drives for 3 - 4 years.

 

If your happy with your SDD's then it's okay! :)

 

The Sandisks uses TLC memory cells. They are cheaper as the Samsung Pro's but that uses MLC memory cells. If I'm correct MLC memory cells can do more writes. So I have to figure out to go for a cheaper TLC model or a Expensive MLC model...

Link to comment
21 hours ago, trurl said:

 

You might reconsider how you use cache. There is no requirement to cache user share writes. 

 

 

This, until very recently, was THE reason for a cache on unRAID.  It's only the past year or so that cache has been used for Docker and the likes.

 

unRAID still isn't fast enough to do direct array writes at gigabit line speed, so using a cache drive for user shares is very much still the main use scenario.

Link to comment
1 hour ago, HellDiverUK said:

unRAID still isn't fast enough to do direct array writes at gigabit line speed,

 

Newer hard disks have much higher transfer rates, e.g. my new 10TB disks have an average transfer rate of 200MB/s (max at 270MB/s).

Transferring large files directly to the array is limited by my gigabit connection ?.

 

image.png.cdafa75f4a2ed1d2be107181d3c25bee.png 

Link to comment
2 hours ago, HellDiverUK said:

unRAID still isn't fast enough to do direct array writes at gigabit line speed, so using a cache drive for user shares is very much still the main use scenario.

If you are willing to spin up all your disks it's getting closer.  Using Turbowrite I get a minimum of 70MB/s and more typically 90+MB/s.  Under optimal conditions (say copying a large BD rip) I frequently get full 1Gb line speeds  That's using a mix of 3TB and 6TB disks, and as boniel points out disks are only getting faster.  

Link to comment

A nice thing of the cache disk is that not all drives spin up. I have a couple of drives with tv-shows and if there is a new episode it's nice that it's written to the cache drive. Only I'm not sure how often Sonarr access the tv-shows and thus spin up the drives.  

Edited by MvL
Link to comment

I'm running a different route, to keep down spinning disks.

 

I have duplicated the directory trees for a large number of drives in a LMDB database.

I have a FUSE app that reads from the database and presents a virtual file system.

Really small files are duplicated into the database.

Semi-small files are duplicated to an SSD mirror.

For larger files, I normally have the first part on SSD.

For some special file types, parts of the files are duplicate to SSD - for example all information related to ID3 tags in MP3 files.

 

This means that it's possible to browse the file systems with only the database online.

And a media player can scan and index photos or music files based on data cached to SSD - it's not until play time that the FUSE app needs to make requests to the original backing store.

 

 

I'm currently busy on improving the commit logic for new data.

 

The main reason for the above is that it's part of a distributed backup solution - the backup server does deduplication of unique files and keeps track of which file systems that contained references to the different files. And the backup server can then make sure that photos are distributed to multiple storage locations.

 

Since it's part of a backup system, the files are immutable. So the FUSE app doesn't need to worry about files changing and no longer match the database information.

 

Link to comment

Looks like the Samsung 970 Pro nvme drives are out now if you want the latest and greatest.

 

I'll will be replacing my current cache drive which is the famous $99 Black Friday Crucial MX300 750GB sata drive. The new Samsung 970 Pro 512GB nvme drive is smaller but I need the speed for my virtual machines so I just put an order in for one. I know everyone here would recommend dual cache drives in a BTRFS pool so I'll probably order another one soon. I hear along with redundancy with dual matching cache drives you also get faster speeds.

Link to comment

This is a little bit of a moneybags solution, but, if budget isnt an issue then an intel optane 900p add-in card.  Added bonus of not taking a slot on my jbod controller either.

 

https://www.intel.ca/content/www/ca/en/products/memory-storage/solid-state-drives/gaming-enthusiast-ssds/optane-900p-series.html

 

I bought a 280gb model for my cache drive and am now regretting not getting the larger one.  I want to replace it with the 480gb model but I cant stomach the thought of wasting the existing drive.  Didnt take UHD filesize into account when I was sizing my cache.

 

Maybe one day Ill get my 10G network card working with unRaid and actually see useful performance from my cache too.  

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.