I wonder if anyone can answer this regarding unraid write speeds:  With the quality of hardware that you can choose, it seems that built-from-scratch unRAID servers seem to be more powerful than equivalent consumer NAS's.  However, reading various posts on here suggest that write speeds (without a cache disc) hover around 25-40mbps, and up to 50mbps with a cache disc.

 

On my current NAS (Thecus N7700) I can get anywhere between 50mbps-80mbps, and a friend's Synology 1010+ averages around 70-90mbps - why is unRAID so slow, by comparison?

 

I know everyone says "write speed isn't important", but it is to me.  Ok so it's not the bee-all-and-end-all, but with 14TB of data to transfer and regular blu-ray ripping, it's more of an inconvenience.

 

Can anyone shed any light on this?

 

Apparently cache discs do speed things up, but I've read various comments from people saying "don't bother" and that there's a bigger chance of a HDD failure using a cache disc.  I may have misunderstood that, but could someone clarify and explain why this is the case please?

 

Thanks

With unRAID, for every write i/o it has to perform 4 i/o operations (2 reads and 2 writes). unRAID only writes the data to a single data drive. The benefit to this approach is it only ever has to spin-up the data drive being written to and parity drive. It leaves all the other data drives spun-down. In a 10 data drive system, if you write 20 Megs of data, all 20 Megs of data is written to 1 single data drive.

 

The other consumer NAS's you talk of keep ALL the drives spun up at all times and spreads the data between all those drives. In a 10 data drive system, if you write 20 Megs of data, only 2 Megs of data is written to all 10 drives in parallel. This is where their speed comes from. The down side is they must have all the data and parity drives spun up at all times.

 

Here is how unRAID works for writing when writing New Data to Sector N through Sector N + (Number of sectors to be written):

 

1a) Read Old Data from data drive for Sector N

1b) Read Old Parity Data from parity drive for Sector N

 

2a) Calculate new Parity Data given Old Data, Old Parity Data, and New Data

2b) Wait for data and parity drives to rotate drive heads back to Sector N

 

3a) Write New Data to data drive for Sector N

3b) Write New Parity to parity drive for Sector N

 

4) Repeat steps 1a/1b through 3a/3b for Sector N+1 through Sector N + # of Sectors to be written

 

Steps 1a/1b and 3a/3b are done in parallel. Steps 2a and 2b could be done in parallel but I'm not certain they are. Step 2a is very quick and takes nearly no computer time at all. Step 2b is where the rotational latency of the drives come into play so 7200rpm drives will perform faster than 5400rpm drives.

 

 

The benefit of unRAID is it leaves all the drives spun down when possible except for those involved in writes or reads. It also allows for a mix-and-match drive setup with the only limitation that the parity drive is as large as or larger than the largest data drive.

 

If you're so concerned with write speeds then using a cache drive can speed up your writes. If those write speeds aren't up to your liking then unRAID is NOT for you.

 

Also, there is a short-cut that can be performed with the initial loading of data to unRAID. This short-cut is to not enable the Parity drive until AFTER all the data has been transferred. This should allow for loading of initial data as fast as the drive can write and/or you can transfer across the network. It's not really a short-cut as once the Parity drive is added, you must then calculate the parity information for the drive array. It just shifts the initial parity calculations from being done on-the-fly to after-the-fact.

 

The cache drive is a temporary landing-zone for inbound files. There is a scheduled task that by default is setup to run once overnight. This task is called 'mover'. It moves the files from the cache drive into the parity protected array. The 'mover' task can run as often and frequently as you like with a little tweaking or through use of community addons.

 

This region, cache disk, is not protected by parity. Given that, there is a possibility of the cache drive failing before the data is moved from there and into the parity protected array. The likelihood of the cache drive failing should be no different to the normal data drive or parity drive failing, but it's there none-the-less.

 

The reason most will say not to use the cache drive is the parity protection of their data exceeds the benefit of slightly faster writes. In many cases the writing of data at 30 - 40 MB/s is fast enough, so writing at 60-80 MB/s without data protection is not worth it. The cache drive was originally used when typical writes to the array were slow, down around the 10 MB/s. Since then the write speeds have tripled or quadrupled.

 

There is one benefit to using a cache disk. It works well for temporary file writes for processes such as downloading from torrents or usenet. It can also serve as a "warm spare" should you have a disk failure if it's as large as your data or parity drives.

 

I wish there was a thanks button 

 

Are you saying that 7200rpm drives are better for unRAID than 5400rpm drives?  (in terms of write speed).  In reality what difference would this make to the write speed?

 

I've actually got 9 of these currently:  http://www.scan.co.uk/Products/2TB-ST3200542AS-SATA-HDD

 

7 of them were from the same batch (which in hindsight was not a good thing to do), but they've run faultlessly for the last 12 months, running 24/7 (I had one failure in the first week which was changed out).

 

Can you answer my question re: the cache drive?

 

Thanks

Updated previous post at the end to include more information on cache drive.

 

Myself, I use 5400-5900 rpm drives since the majority of information in my array is multimedia data. It is written once and read many times. There is no need for obtaining that information as fast as possible. The blu-ray rips, even if uncompressed, need only be read as fast as 50 mbit/sec (this is 6.25 MB/sec). That is the absolute upper limit of blu-ray movies. Most typical uncompressed bluray movies use 20 - 30 mbit/sec. Compressed blu-ray rips/re-encodes naturally use lower bitrate settings and are not as demanding. As you can see, any drive should be able to read data faster than the 6.25 MB/sec.

 

Even if your data drives are 5400-5900 rpm green drives, you might see a speed improvement from using a faster parity drive, if and only if you have a lot of simultaneous writes to multiple drives in the array. If you only write to a single drive at a time then having a faster parity drive will not provide any benefit. This is because the steps to write must be done in parallel, and as such you're limited to the speed of the slowest component.

2b) Wait for data and parity drives to rotate drive heads back to Sector N

 

I can't help thinking that that is wrong in two senses ... or, at least, will lead to possible confusion!

Why is unRAID so slow with write speeds compared to consumer NAS's?

 

One word:  Striping.  unRAID does not stripe, which is why unRAID is safer and you can always read your data from drives that don't fail.  I.e., you never lose all your data.  Striping is, however, faster at writing.  With a 10 drive striped raid, you lose 2 drives and all 10 drives worth of data is gone.  With unRAID, that same 10 drive system with 2 failures, you still have 80% of your data intact.

 

Rotational speed is less important when you have large buffers on the disk.  Modern drives that do whole track buffering of reads and writes, with 32K and up of buffers, will not see much difference in write speed in unRAID between 7200 vs. 5400 RPM.

 

With the current version of unRAID, with all else (mobo, NIC, LAN, etc) presenting typical performance, WD Black 7200 RPM 2TB drives are not going to turn in significantly better write speeds in unRAID than WD Green 5400 RPM 2TB drives.

Nothing is incorrect with that statement. What did you think was wrong with it? Disk drives have multiple platters and thus multiple drive heads, at least one per platter.

 

Would this have been any less confusing?

 

2b) Wait for data drive to rotate drive heads back to Sector N

2c) Wait for parity drive to rotate drive heads back to Sector N

 

 

I hope it's OK to intrude here. I am struggling with the same question as OP and above feedback it just awesome. I'm expecting my hardware next week (first project..) and I'm about to set it up with Unraid. One thing I'm still a bit concerned about are my Usenet DL speeds. No doubt a n00bish question; when using a cache disk, would the write speed (from Usenet to server) be similar with Unraid as with any other server OS?

 

Thanks!

What is your internet connection speed

Fiber 100 Mbit/s

 

FIBER 100/10

Nothing is incorrect with that statement. What did you think was wrong with it? Disk drives have multiple platters and thus multiple drive heads, at least one per platter.

 

Sorry ... perhaps I'm being too pedantic (and my comment was a little 'tongue in cheek') but:

 

The only practical magnetic drive technology I can think of where the heads rotate is on tape drives (eg VHS).  On disk drives it's (usually?) the disk which rotates (while the head traverses the disk to the correct track).

 

Secondly, I'm sure that the unRAID software has absolutely no idea which sector is currently under the head, so waiting for the disk to rotate before sending the data to write seems most unlikely.  I have to believe that unRAID sends the write command, together with the data to be written, asynchronously with respect to the angular position of the disk, and leaves it to the drive to ensure the correct sector is under the head before writing the data.  I guess that it would be possible for the software to wait for the write command to complete before moving on to processing the next sector.  However, in these days of command queuing and data caching, it seems unlikely that the write will have taken place before command completion is signaled.  The most likely point at which unRAID will have to wait during this write sequence is when, at some point, buffers and caches become full and it is necessary to wait for the data to be supplied in response to a read command.

 

Having said all that, the principle of your description is correct, and does explain why unRAID writes are comparatively slow.

 

As an aside, many years ago, I did work on O/S software where it was necessary for the floppy disk driver to wait on a signal that the sector hole had passed, before clocking the data out.  Then fdc chips became more intelligent and the software no longer had to know anything about the angular position of the disk.

I hope it's OK to intrude here. I am struggling with the same question as OP and above feedback it just awesome. I'm expecting my hardware next week (first project..) and I'm about to set it up with Unraid. One thing I'm still a bit concerned about are my Usenet DL speeds. No doubt a n00bish question; when using a cache disk, would the write speed (from Usenet to server) be similar with Unraid as with any other server OS?

 

Thanks!

 

By using a cache disk you will be writing to the disk the fastest it can be written (ie no calculations) so the speed would really be limited to the write speed of that drive. The array does not come into play here. Someone feel free to correct me if I am wrong.

The only practical magnetic drive technology I can think of where the heads rotate is on tape drives (eg VHS).  On disk drives it's (usually?) the disk which rotates (while the head traverses the disk to the correct track).

 

Ah true, perhaps I should have said positions the drive heads and wait for the platters to rotate into position to write. Though I was trying to keep things at a high enough level. I could get into specifics down to the Linux md kernel driver and the scsi/sata libata kernel drivers, but that would be way too detailed.

 

Even with all the disk track buffering and asynchronous i/o, I wonder if something wouldn't be amiss without mentioning rotational delays. Would it be simple enough to just glance over it with slower rpm drives typically write slower? What might be really great to demonstrate this is to have an overview in graphical time or command slice style of say 10 writes to the array intermixed with one another.

 

As an aside, many years ago, I did work on O/S software where it was necessary for the floppy disk driver to wait on a signal that the sector hole had passed, before clocking the data out.  Then fdc chips became more intelligent and the software no longer had to know anything about the angular position of the disk.

 

I worked with several copy protection schemes that dealt with similar low level details. It was quite a pain in the ass. One scheme was 'custom layouts' where the physical sectors were not layed out in typical fashion; to test this you'd position the head at sector N, begin timer, send command to read sector X, end timer, and if it came back too fast the media likely was blind copied instead of using your original media. There was also 'phantom sectors' where you'd use a custom format layout and have multiple sector X's with different content scattered throughout the media; to test you'd position the head at sector M, send command to read sector X, position the head at sector N, send command to read sector X, and compare the reads 1 and 2, if the sectors X contents read were identical then it was a blind copy instead of using your original media.

 

It's so much easier now to just use an online key authorization system.

One thing I'm still a bit concerned about are my Usenet DL speeds. No doubt a n00bish question; when using a cache disk, would the write speed (from Usenet to server) be similar with Unraid as with any other server OS?

 

Just to cover all bases... Since you have a high speed net connection, be sure to get a high speed usenet provider that does not limit your bandwidth. Make sure you have a gigabit network setup and working from your server up to your internet connection point (fiber router/terminal). Make sure your server has plenty of memory, you'd want at least 1 Gig and make sure to have SabNZBD+ setup to use ram cache by setting "cache_limit = 512M" or larger inside the sabnzbd.ini file. This will limit disk reads and writes and most of the disk latency when it's fetching the smaller article parts and allow it to do most of the assembling into file segments in memory (typically rar segments .rar, .r00 ... .r99) since most file segments posted on usenet are 15-50 Megs in size.

 

Even when writing directly to a parity protected array, assuming a modest write speed of 30 MB/sec, that translates to 240 mbit/sec which is over twice as fast as your internet connection.

 

With that said and setup, your only speed limit will be how fast you can issue get commands, how fast the provider can send, how fast the data can be routed to your server, how fast your server can process the data, and how fast your server can write to the disk.

 

Your speed limitations will be in the post processing which has nothing to do with your internet connection speed. This is where the software reads the file segments from disk (.rar or .zip parts) and extracts the contents to be written to disk. This is where using a cache disk for storing of the initial file parts (.rar or .zip parts) and using a different destination disk for extracted contents can provide benefit. That will prevent a single disk from thrashing about as it does the reads and writes.

 

Thanks a lot! When on this board, I'm learning all the time!!

 

I will tweak SABnzbd again as soon as I'm (Unraid) operational. With my current setup (running SABnzbd on an iMac writing directly to a Thecus NAS) changing "cache_limit" has (it seems) no noticable effect. I think I read somewhere that when leaving this blank, SAB will use what it needs.