Hi Guys,

 

This is more of a long term roadmap project probably, but it's worth starting a thread on it, even if it's for my own understanding of where write speed is lost.

 

From watching my own server I have found the following:

 

1. To cache root (i.e. writing directly to the cache drive, not via a share) write speed is maxing out the network, i.e. 100MB/sec+.

2. To cache disk write speed is less than that (varies from beta to beta, but it's never as good as direct-to-drive), say 75% for the moment.

3. Parity drive protected shares are 20MB/sec.

 

CPU usage is never 100% and cores are always at 800Mhz (i.e. doing **** all).

Memory usage doesn't change

HD writes according to UnMenu is well well WELL below what a disk can actually achieve.

 

Now my questions are:

 

1. Why isn't a cached share as fast as direct to drive, where is the overhead loosing us performance? Idle CPU means its not doing a lot!

2. Where is the parity performance lost? Is it just down to drive IO - we are at bit level and thus drive performance is poor?

 

However if we are writing constantly to a block of the parity drive then why aren't we getting decent continuous writes?

 

Will P+Q parity reduce this down even more?

 

Problem is, even with a cache drive, we are generating more and more data onto bigger and bigger disks and one day 20MB/sec won't be good enough because we will be sending it to the cache drive quicker than it can write it!

 

Ideas/thoughts?

Most of the performance lost when writing through the user shares instead of direct to disk share is because of the extra layer that's involved, namely the user-space filesystem [ http://en.wikipedia.org/wiki/Filesystem_in_Userspace ]. This is the /mnt/user/ provided by 'shfs'.

 

If you want to know more about the actual limitations imposed on parity writes, then read the following thread: http://lime-technology.com/forum/index.php?topic=9989.0

Problem is, even with a cache drive, we are generating more and more data onto bigger and bigger disks and one day 20MB/sec won't be good enough because we will be sending it to the cache drive quicker than it can write it!

 

Ideas/thoughts?

At that time you'll be limited by the network speed.  Or, if not, by the write speed of the cache drive.  If those are not fast enough, then you will have outgrown unRAID and will need to move to a faster solution. (or 10,000 RPM disks, or SSD disks with no rotational latency)

 

unRAID has come a LONG way from its early days when it could barely do 9MB/s.  The cache drive was the solution to be able to keep up with recording HD streams from HDTV tuners in client PCs.

 

Don't worry, if you write faster than ANY device can write, the writing will slow to the speed of whatever bottleneck there might be.  I can pretty much guaranty that when dual-parity (Reed-Solomon or Diagonal Parity) is implemented at some point in the future, it will NOT be faster.  In fact, if anything, it will be slower writing, as yet another disk must share the bandwidth on the buss)

 

If all you want is speed, unRAID is the wrong solution for you.

 

Joe L.

Most of the performance lost when writing through the user shares instead of direct to disk share is because of the extra layer that's involved, namely the user-space filesystem [ http://en.wikipedia.org/wiki/Filesystem_in_Userspace ]. This is the /mnt/user/ provided by 'shfs'.

 

If you want to know more about the actual limitations imposed on parity writes, then read the following thread: http://lime-technology.com/forum/index.php?topic=9989.0

 

Ok, in that case why is that the case.

 

If it's due to software, not hardware, then surely something somewhere (CPU, Memory, IO) is being maxed out? No? If it isn't then gains can be had.

 

Edit: Partially read the other thread.

 

From what I understand it's due to the way UnRAID reads and writes and thus it's HD I/O limited?

 

@ Joe L. Something like Time-Machine don't work well with a cache disk, therefore long term, performance with parity should be on the list, but not necessarily high up it!

then surely something somewhere (CPU, Memory, IO) is being maxed out? No? If it isn't then gains can be had.

When writing through the user-share file system there are more context switches than when writing to a disk directly.  A context switch is a very time consuming operation (relatively speaking).  There are more context switches involved when the fuser file system is involved.

I think you are overlooking the fact that unRAID is not designed to be fast raid array.

It is more like long term storage with a parity drive to protect your data.

 

In the end, the unraid limit is the disk IO's (Yes i read about the possibility of driver tweak, I would not count on it happening in the short term).

 

I am getting some decent write speeds from my setup. but again, it is nothing compaired to my raid arrays.

 

I would assume you could also do some tweaks if you MUST have some better speeds.

 

To start, 2 NEW 7200RPM drives. One ror your TimeMachine backup drive and one for your parity drive. I say new drives meaning latest technology with higher density platters and fewer platters per drive then the older technology. put those on your motherboard directly or their own PCIe x4 or better controller to avoid bus saturation.

 

There are other hardware raid options you can do, but that defeats the point of unraid.

 

You can always schedule your TM's when your sleeping or at work, along with other file copies.

 

for other data copies to the unraid, there is the cache drive.

 

I also have a suspicion that in a few years, we will see 500gig-1TB SSD's at a cheap price.

I am sure before long, mechanical drives will go the way of the dodo bird.

 

The other option is some other OS/Device for you. freenas, ZFS, Hardware Raid, Drobo, ETC. the list goes on....

 

I use my unraids purely for storage. anything that needs lots of disk IO's or speed (par/rar or databases for example), I use raid arrays.

I then offload anything I wont change for a while to unraid.

 

one thing I am building right now is an ESXi server that has both a windows server with a fast raid array and unraid (plus other hosts) on the same box.

I could in theory use my windows session as a high IO cache for the unraid side.

 

 

After all my mindless run-on.. think of unraid as the tortoise in the rabbit and tortoise story.