Bypassing the Cache drive?


Recommended Posts

I'm new to unRAID but loving it!  

 

I'm copying about 6TB of data from my old storage (HP MSA60 attached to Win2012R2 server), I think I may have made a mistaking costing me a lot of time.  I'm copying to my Media share which has the cache drive enabled.  The cache drive is currently a standard 4TB SAS drive (same as the 4 drives in the RAID and the parity drive).  

 

So the cache drive is getting close to full.  I stopped my transfer and made sure mover is running.  But it occurs to me that I'm spending a lot of time transferring (unfortunately 1Gbps connection, seeing 800Mbps transfer rate), and then I have to wait for the cache to catch up before I can finish my transfer.  Would it have been faster when transferring a lot of data at once, to copy it directly to the RAID?

 

Also, why is writing the RAID slower when there are 4 disks to spread the load vs 1 cache drive?  Is it because of the calculations required to build the parity?

 

Thank you

Link to comment

Think of the entire data stream as a pipeline. The flow rate is determined by the narrowest pipe. 800 mbps is about as fast as you can hope for due to the packet overhead on a 1 Gbps connection. If you're using standard 5400 RPM drives in your array, you can get anywhere from 50-100 Mbps sequential write speeds, which means that your standard home gigabit ethernet saturates your drive write speeds. This is why a lot of us don't bother with the expense/hassle of a 10G network. So would it have been faster? Probably not, but it might have been more convenient.

 

The reason it's slower to write to the "RAID" (it's not actually a RAID array, hence the name, unRAID) array is because there's no striping in unRAID, you're basically writing to one disk at a time while unRAID does the redundancy calculation read/writes on the other drives.

 

 

Link to comment
36 minutes ago, zwolfinger said:

Also, why is writing the RAID slower when there are 4 disks to spread the load vs 1 cache drive?  Is it because of the calculations required to build the parity?

Files on the array are always constrained to a single drive (each drive is a self-contained filing system).   Also Unraid by default uses a read-modify-write approach which involves reading the target sector from the target drive and the parity drive(s), calculates the changes involved,  waits for a disk revolution, and then writes out the target sector to the target drive and the parity drive(s).    This has the advantage that it is not necessary to keep all drives spinning but it does slow down write operations significantly.

Link to comment
3 minutes ago, itimpi said:

Files on the array are always constrained to a single drive (each drive is a self-contained filing system).   Also Unraid by default uses a read-modify-write approach which involves reading the target sector from the target drive and the parity drive(s), calculates the changes involved,  waits for a disk revolution, and then writes out the target sector to the target drive and the parity drive(s).    This has the advantage that it is not necessary to keep all drives spinning but it does slow down write operations significantly.

That reminds me of an important optimization he can make since he didn't say what those write speeds to the array were.

 

zwolfinger, you can improve your array write performance by changing the tunable to "reconstruct write":

 

image.thumb.png.a92c84ac4802fc635f034c1963969046.png

Link to comment

Thanks guys!  That clears it up for me.  

On the md_write_method, can I make that change, copy my media over, and then change it back?  I was reading about it and don't want to cause stuttering in my video playback.  

 

Can I change it without having to restart the array?  I'm currently in the middle of a parity check as well.

Link to comment

Looks like everyone missed the most important part of your problem. 

 

Don't cache the initial data load. Cache just gets in the way since there is no way to move to the slower array as fast as you can write to cache. 

 

And trying to do a parity check at the same time as loading data will make writing and checking both slower since those operations will compete for the disks.

 

Some even wait until after the initial load before even installing parity. 

  • Like 1
Link to comment

And in case you didn't know, moves from cache to array by default only happens daily in the middle of the night. Mover is intended for idle time, not while writing data. Moving and writing also slow each other down since they will compete for the disks. 

 

That Turbo write method they mentioned actually gets all of the disks involved with parity updates, instead of just the disk being written plus parity, so that is definitely a tradeoff and might not help much if you are trying to do too many things at once, another case of competing for the disks. 

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.