Is anyone here actively using an SSD as a cache drive?

 

I was about to go down this path, but most of the "value" SSDs (like the Intel X25-M Gen 2) has mediocre sequential write performance typically less than 100MB/s.  A good rotating disk can do achieve this.  It wouldn't have the same access time, but for large sequential writes I don't believe that would make much of a difference.

 

Lately, I have seen some good buys on small 30GB SSDs with decent write performance (over 150MB/s), which gave me an idea... Could I use the onboard intel hardware RAID controller to stripe a pair of 30GB SSDs for write performance in the 300MB/s range?  I understand that there are other bottlenecks, but this would give me a reasonable 60GB of storage on the cache drive and certainly alleviate the media bottleneck.

 

Has anyone attempted this?  I believe this would provide me with a constant 50MB/s transfer speed over the wire and enough cache space for the largest files I would ever transfer.  Power consumption would be minimal (many draw only 0.1W at idle).

 

I am setting up a 4 bay chenbro NAS case and the onboard controller has 6 ports, which would work out perfectly with this configuration.

 

Some comparisons with X25-M G2 sequential write performance:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3607&p=4

Is anyone here actively using an SSD as a cache drive?

 

Lately, I have seen some good buys on small 30GB SSDs with decent write performance (over 150MB/s), which gave me an idea... Could I use the onboard intel hardware RAID controller to stripe a pair of 30GB SSDs for write performance in the 300MB/s range?  I understand that there are other bottlenecks, but this would give me a reasonable 60GB of storage on the cache drive and certainly alleviate the media bottleneck.

 

I don't think you can do this at the current time. Motherboard raid drivers are usually fake or software raid. You will need add'l drivers and udev devices.  You may be able to do this with unRAID on a full slackware distro after recompiling the kernel with the proper drivers.

 

Do you really need to move data that fast? Faster then a single SSD can support?

Everything I've read here states the network is the bottleneck, not the drives.

 

On sale, with rebate, OCZ is sometimes available in the $150 range for 60gb.

I don't think you can do this at the current time. Motherboard raid drivers are usually fake or software raid. You will need add'l drivers and udev devices.  You may be able to do this with unRAID on a full slackware distro after recompiling the kernel with the proper drivers.

 

Is this true?  I have never tried using it in on any Linux operating system, but the onboard ICH10R controllers configure the stripe set in hardware.  I didn't realize any driver was required for this.  I believe the same controller logic is used on the H55, x58 and other modern chipsets.

 

Regarding the performance, yes - the Gigabit ethernet is definately a bottleneck.  However, when I measure data throughput I see about 5-10% difference between a 100MB/s rotating drive and a 80MB/s rotating drive over the wire.  A 70MB/s (write) SSD like the Intel X25-M would be even worse.  

 

Although this is not a huge performance difference, I thought a RAID 0 stripe set of the cheaper 30GB SSDs would give me maximum cache drive performance with minimum power consumption (0.2W Idle) and enough capacity to move my largest files around.

Here is a graph that shows the read performance among several hard drives that range from 80MB/s to 110MB/s on the exact same system (the i3-530 platform).  This is over the wire performance.  Since the cache drive is not impacted by the "parity penalty", I would expect cache performance to scale similarly.

 

Note that the Seagate ST31500 already had the fastest part of the drive filled, so it was operating at a performance penalty to the other two which were empty.

 

Vertical Axis is kB/s, Horizontal Axis is File Size in MB (131MB - 8GB).

 

Gary, not sure this suggestion will work for your system but, have you considered just picking up a Seagate 7200.11 1.5TB 7200rpm drive and short stroking it to about 300GB? It demolishes a Velociraptor in both sequential reads and writes across the board and would easily shift the bottleneck over to your network. Only downsides compared to SSD in this application would be idle power consumption and heat, but that can be diminished somewhat by just having the drive power down after a certain idle time.

 

http://www.techwarelabs.com/seagate_1-5tb-mod/all/1/

Thanks for the suggestion, PhatalOne but the case has additional space only for a 2.5" HDD and I am also trying to maximize performance and minimize my power draw at the same time.

 

I already have a couple of the vRaptors here.  The review I read had it performing almost as well as the vRaptor if I recall.  I don't remember it being better.  In addition, the vRaptor is a 2.5" notebook sized HDD and consumes much less power.  However, it uses a giant heat sink that makes it take up the full 3.5" bay or I might have considered doing this.

 

I'm really just trying to determine if I can run onboard ICH10R raid to stripe one pair of drives and run the others as stand alone disks on the same controller and have the configuration recognized properly by unRAID OS without any performance penalties.

 

I may be better off waiting for a single 80GB sandforce SSD that will hit 200MB/s write speeds and not complicate things so much.

 

I'm really just trying to determine if I can run onboard ICH10R raid to stripe one pair of drives and run the others as stand alone disks on the same controller and have the configuration recognized properly by unRAID OS without any performance penalties.

 

Try installing slackware on a temporary setup and see if you can get raid 0 working on test drives.

Then check what drivers/device nodes it is using.

 

Another way to raid 0 the drives is with a silicon image chipset.

This WILL work in increasing drive size.

But chances are you may not see a performance improvement.

Try installing slackware on a temporary setup and see if you can get raid 0 working on test drives.

Then check what drivers/device nodes it is using.

 

Yea - if noone else here has attempted this, I will just have to test it out once I get my next motherboard in a couple weeks.

Has anyone attempted this?  I believe this would provide me with a constant 50MB/s transfer speed over the wire and enough cache space for the largest files I would ever transfer.  Power consumption would be minimal (many draw only 0.1W at idle).

 

I get that sustained transfer rate (and more) to my 500GB sata cache drive.

 

I get not far off that (~40) to the parity protected array directly.

 

Spending that much money on SSD disks to get such a paltry write goal seems odd. You should easily be able to hit that with the spinny stuff.

boof -

 

I don't believe we are measuring things in the same way.  With large file sizes (for example, 8GB files), I have never seen 23MB/s writes exceeded even with VelociRaptor drives acting as Parity and Data (it was only a test rig).  The same system with vRaptors produce around 44MB/s continuous read.  This is without a cache drive.

 

I measure with the free IOzone test program using this command line from my Windows 7 desktop:

 

iozone -Rab RESULTSFILENAME.xls -i 0 -i 1 -+u -f \\tower\disk1\filetest -y 64k -q 64k -n 64k -g 8G -z

 

This is a non-destructive test that accurately measures your true read and write transfer rate without OS buffers, etc.

 

 

I don't really care whether OS buffers at either end are being used or not. At this point you can start saying the hard disk controller cache is also artificially increasing your rates.

 

At the end of the day I copy a file from a client OS to unraid as the server OS.

 

How each OS handles, in terms of buffers etc, this process I largely don't care (except of course where there are performance benefits to be had) so long as I see a perceived decent transfer rate.

 

I do see this with no problem using normal drives over large files.

 

You can argue thats not the actual through to disk rate of my drive(s) but it really doesn't matter. The transaction, as far as I'm concerned, completes. There's little more I can do.

 

Removing all the write optimisations and buffers in the sata controller and the disk interface itself would ruin your transfer rates as well. But we all still rely on them (as theres not much we can do to disable them - and why would we!).

 

So I find it even stranger that you understand you too can get 'real world' figures similar to mine yet still want to overegg the underlying hardware to such an extent.

 

Each to their own but I think you're making your own problem at the scale an unraid server sits.

 

I do have to worry about this sort of thing in my day job where a great proportion of budgets is driven by IOP requirements. But for unraid on a gigabit connection? Save your money and expand your store.

 

Live with your real world high transfer rates even if they are being cushioned in memory along the way.

boof -

 

My point was that your transfers can be faster than they are on rotating media.  Eliminating these OS enhancements when benchmarking is just a way to put the measurement on a level playing field between platforms.  Your actual write speed is still limited by the network and the server. 

 

How are you going about calculating your throughput, exactly?  Making this new server as fast as it can be is more of a hobby for me.  I'm not suggesting the extra 10MB/s is worth the investment to the average person.

 

 

Throughput is 'calculated' by comparing what windows claims during a file copy dialogue, what the windows network stack and disk i/o at the time claims it's doing - and then the reverse at the other end with unraid and bwm-ng / bmon.

 

You then compare by the pen and paper size of file versus time taken to 'copy' (which of course doesn't mean fully flushed down to disk) to check the figures.

 

Highly unscientific but all enough in agreeance. And getting much better with each bump of unraid and the linux kernel.

 

I could test using iozone or any other plethora of benchmarking tools - but my server isn't there to benchmark it's to copy data onto so that's the best test for me.

 

I remember your other thread - in which case fair enough. Although with your seemingly money no object approach then ultimately the thing slowing down your server the most will be unraid's lack of striping...

 

 

 

What is the point of all this optimization?

 

unRAID is not designed to be like a fast RAID system, it's designed to hold large media collections, which are then streamed at a relatively low speed.

 

The lack of striping gives several advantages, but results in a drop in speed.

 

If you want speed, go with a conventional striped RAID.

 

I'm happy with sustained protected write speeds on my 4.5.3 system that are now over 40MB/sec, but I wasn't that bothered when they were at 10-15MB/sec.

Most unRAID setups are about huge storage space with minimal wasted space and low risk of losing an entire array in one shot, not about speed.

 

Again, whats the point?

neilt0 -

 

Not trying to stripe my data, just the cache. 

 

I also don't use my unRAID primarily to stream media.  I use it to backup large amount of data and I want the write speed to be as fast as it can be.  Again, some may not see any benefit in eeking out another 10MB/s.  This is just somethign I am personally interested in tinkering with. 

I think perhaps the point we're trying to make is that your time, and money, would be better spent on eliminating the obvious weak point that is unraid in this situation.

 

Taking your existing hardware and creating a software raid-5/6 volume will give you much better performance with no extra cost (presuming disks  are uniform size or you don't mind rounding down to the smallest disk).

 

If performance is your goal then the answer seems clear...

 

It's your perogative of course but many people here will likely struggle to understand the time and financial outlay you're talking about with regards to unraid!

neilt0 -

 

Not trying to stripe my data, just the cache. 

 

I also don't use my unRAID primarily to stream media.  I use it to backup large amount of data and I want the write speed to be as fast as it can be.  Again, some may not see any benefit in eeking out another 10MB/s.  This is just somethign I am personally interested in tinkering with. 

 

I know what you're doing, but you're trying to make unRAID in to a system it's not designed to be.

Another angle to consider is the fact that a person can run with a large number of low power consumption, low cost green drives and spend a little of the money saved on a small SSD which will idle at 0.1W.  This reduces the cost of the drives substantially vs higher performance drives while providing a very nice reduction in power consumption for large arrays.  

 

With the SSD cache drive, the write speed for the user is far better than an array filled with high performance drives and the power consumption is optimized.

 

I hear what everyone is saying regarding performance and agree that I could blow away this performance by going to a full hardware RAID 5 system for my data and use freeNAS or the like... but I really like the functionality of unraid and the flexibility it offers me on drive configuration, so I plan to stick with it.  Striping the SSD is probably overkill for any sane person - I just wanted to know if it would work because I had an opportunity to pickup two smaller units for a good price.  Besides, it's my money I'm wasting, so there is no reason for anyone to become personally upset or concerned!

 

And what do you do when you wear out the cells of the SSD?  The absolute WORST place to put cache would be on an SSD unless you want to replace it annually.

 

The use-delete-reuse cycle of a cache drive will quickly tank SSD performance.... that type of activity will mean trim needs to be run frequently to restore performance.

 

How do you run Trim on Linux?

bubbaQ -

 

I believe modern SSDs are estimated to have 2 million write cycles of endurance per cell.  Since I would only write to each cell once per day at most before the cleanup (two writes), I don't fear any short term issues there.  Why do you think this would wear out so quickly?  Maybe I don't fully understand how unRAID manages the cache drive, but I was under the impression that your writes go to the cache drive and then each day unRAID performs a cleanup where it moves this data from the cache drive onto the data drive and erases the file from the cache.  

 

You have a good point regarding trim.  Deleting files does not help with this SSD storage degregation.  I'm not sure how this adds up over time (i.e. under what conditions would the SSD performance actually degrade to something worse than a rotating drive).  Linux has had trim support for some time, but I don't know if this is supported in unRAID or not.  In any case, TRIM operations can't be performed on a stripe set.  

 

 

And what do you do when you wear out the cells of the SSD?  The absolute WORST place to put cache would be on an SSD unless you want to replace it annually.

 

The use-delete-reuse cycle of a cache drive will quickly tank SSD performance.... that type of activity will mean trim needs to be run frequently to restore performance.

 

How do you run Trim on Linux?

 

I've read that with current drives and sizes, you can write 20gb per day and the drive will still last for many many years.

 

How do you run Trim on Linux?

 

From what I've read, this is in linux, but the filesystem has to tell the kernel to do the trim. The article also said, this is currently only in ext4.

 

  Linux has had trim support for some time, but I don't know if this is supported in unRAID or not.  In any case, TRIM operations can't be performed on a stripe set. 

 

I do not believe reiserfs has it yet.

 

I still say, if you need that much peformance, look into the areca controllers.

This may allow you to do the striping at a hardware level and be supported in unRAID.

limetech made mention that the areca driver was added to unRAID.

 

Honest to God, I am seriously pizzled as to why would somebody who's goal is high read/write speeds, and who has money for SSDs, and who invests so much human time in trying to reinvent the wheel, why would such a person be tinkering with unRAID?? Take these resources -- human and monetary -- and build yourself a conventional stripped RAID system, and be done with it. What could be more simple?

 

Honest to God, I am seriously pizzled as to why would somebody who's goal is high read/write speeds, and who has money for SSDs, and who invests so much human time in trying to reinvent the wheel, why would such a person be tinkering with unRAID?? Take these resources -- human and monetary -- and build yourself a conventional stripped RAID system, and be done with it. What could be more simple?

 

The initial question and part of the reasoning is valid.

Can we use motherboard raid to do RAID0 with SSD's.

 

1. power. (consider that there are no spindles used when you do writes.

2. Increase size.

3. Speed.

 

Now to me #3 is where many of the disagreements come to.

 

When you get down to it, the cost for 2 30s vs 1 60 doesn't save much and there is probably not that much return on investment in order to gain extra speed.

 

Would I do RAID0 to save power (vs a spindle) and increase size and speed.

If I could, I would do it.

 

But at the current time I rip to one machine and when the drives are full, I rsync over to another. so unRAID speed actually does not affect me.

 

In summary, I think the exploration is worthwhile, I'm not sure the lengths of it are cost effective.

More to the point, why marginally optomize cache drive speed when your LAN is the bottleneck?

 

Throw 4GB in a server and set up a large RAMdisk, and test your writes to the RAMdisk.  When you can write more than 70MB/sec to a RAMdisk on unRAID, then you should start considering a faster cache.... until then, you are just rearranging deck chairs on the Titanic.

 

I like tinkering too -- even on projects that are of little or marginal use -- because I enjoy it.  But I don't kid myself that it is actually going to bear fruit other than its entertainment/educational factor.

 

Striping the SSD is probably overkill for any sane person

 

Not at all.   That is the standard employed by all of the high-performance SSD packages such as the Ocz Z-drive and the Fusion IO.  They just surface-mount multiple SSDs on a RAID card and package it as a single unit.

why would such a person be tinkering with unRAID?? Take these resources -- human and monetary -- and build yourself a conventional stripped RAID system, and be done with it. What could be more simple?

 

1) I am comfortable with the unRAID system and interface.  It "just works".

2) I am concerned about reliable fault recovery on other platforms.  My data in unRAID is completely portable to newer hardware options as they become available.  Likewise, I don't have to have spare drives of an outdated size in case one fails and upgrading to larger drives could be a PITA.

3) I like the ability to upgrade disks individually and add volumes with newer models and non-matching size.

4) I would miss the comradarie and concern for my personal finances which can only be found here in the unRAID forums!