To Cache drive or not to Cache drive?

[johnm160]

Well, you should see a performance increase, as I believe your other drives are 5900 RPM, correct? Why do you think you'd see a performance "hit"?

 

I have a 500 GB 7200 RPM Hitachi cache drive, with my array drives all being green--of mixed Hitachi and WD sizes. I never did a benchmark comparison between the two, but, according to those specs, performance should be increased.  Please I use the cache drive for running YAMJ.

 

Correct my data drives are 5900 RPM, My concern about a performance hit is because the 500GB drive  I am thinking about using as a cache drive is IDE interface not SATA

 

Do you expect to put more than 500GB worth of a data on your server per day? I don't see why that'd be an issue--actually a smaller cache drive would be better. Use a cache drive that's as small as the daily amount of data you'd transfer, plus the size of whatever Applications will permanently reside on your cache drive...

 

And yes, you should get a SATA interface cache drive...

 

I would not think I would exceed 500gb per day since the array is already loaded. If I found some rare instance where I might exceed that I could just run the mover twice that day.

 

But if I have to get a new SATA drive anyway 1tb is cheap enough.

[Mondo]

Just a thought and I haven't been through the whole thread but if space isn't an issue and you are worried about data protection then 2 cache drives mirrored in hardware might be a solution to keep your data protected until the cache drive is flushed. Software mirroring would defeat the purpose but if your MB supports RAID and has a couple of spare 6GB/s ports then it should give fairly decent speed even with green drives... It would also give you a "real" hot spare as you can keep your cache drive "unprotected" until you can replace it.

 

I see some flaws in calling a single cache drive a hot spare as if it has data on it you can't really write safely to a degraded RAID so you would have to move all your data off it before adding it to the array (if you have a lot of data on it that could take longer than getting a new drive).

 

alternatively you could get something like this:

 

http://www.ht.com.au/part/V9527-My-Book-Studio-Edition-II-WDH2Q20000-hard-drive-array/detail.hts in RAID 1 on an eSATA port - not sure how fast they are in mirrored mode though.

 

 

Complete noob so I could be well off the mark ...

[Rajahal]

Just a thought and I haven't been through the whole thread but if space isn't an issue and you are worried about data protection then 2 parity drives mirrored in hardware might be a solution to keep your data protected until the cache drive is flushed. Software mirroring would defeat the purpose but if your MB supports RAID and has a couple of spare 6GB/s ports then it should give fairly decent speed even with green drives... It would also give you a "real" hot spare as you can keep your cache drive "unprotected" until you can replace it.

 

Thanks for sharing your thoughts, and I don't mean to discourage you, but you are indeed 'well off the mark'.  First of all, the parity drive is not involved when reading or writing to the cache drive.  Therefore, changing parity in any way makes no difference in terms of protecting data on the cache drive.  Running a hardware RAID1 on the cache drive is possible and does help protect the data on it.  Some advanced users are doing this with success.  However, it is a complicated topic and not recommended for the new user.  If you don't ever want your data to be without parity protection, then I recommend that you don't use a cache drive at all and just live with the slightly slower speeds.  Many users do this and have no complaints about transfer speeds.  How fast is 'fast enough' is different for every user.

 

Secondly, running a RAID1 on your parity drive also does nothing to add additional protection to your data.  When a drive fails, every other drive is equally important in reconstructing the contents of the failed drive.  Running RAID1 on your parity drive will add extra protection to that particular drive, but it won't help you at all if you happen to have two data drives die at once.  The only way to truly add extra protection to your array would be to run RAID1 on every single drive, regardless of its role as a parity or data drive.  This is of course completely impractical.  At this point you might as well be running RAID10.

 

I see some flaws in calling a single cache drive a hot spare as if it has data on it you can't really write safely to a degraded RAID so you would have to move all your data off it before adding it to the array (if you have a lot of data on it that could take longer than getting a new drive).

 

You make a valid point here.  Generally people write relatively small amounts of data (20 GBs or less) to their cache drive that is flushed every 24 hours.  It is true that moving this data off the cache drive into the array does extend the amount of time that you are operating without parity protection, but not by much.  If you are regularly writing 1 TB of data to your cache drive on a daily basis, then I agree that it would be a mistake to consider that drive to be a warm spare (there's no such thing as a hot spare in unRAID since the array always has to be stopped in order to swap a disk.  unRAID does not support hot swap, only warm swap and cold swap).

 

alternatively you could get something like this:

 

http://www.ht.com.au/part/V9527-My-Book-Studio-Edition-II-WDH2Q20000-hard-drive-array/detail.hts in RAID 1 on an eSATA port - not sure how fast they are in mirrored mode though.

 

That would work, and it is essentially the same as running an internal hardware RAID1 on the cache drive as I described above.  I would personally opt for the internal option, as opening that device up to recover data in a catastrophic failure would void its warranty.

 

Again, thank you for your comments.  I hope my comments don't come across as too harsh, I just want to correct any misconceptions you may have about how unRAID works.

[Mondo]

Thanks for sharing your thoughts, and I don't mean to discourage you, but you are indeed 'well off the mark'.  First of all, the parity drive is not involved when reading or writing to the cache drive.  Therefore, changing parity in any way makes no difference in terms of protecting data on the cache drive.  Running a hardware RAID1 on the cache drive is possible and does help protect the data on it.  Some advanced users are doing this with success.  However, it is a complicated topic and not recommended for the new user.  If you don't ever want your data to be without parity protection, then I recommend that you don't use a cache drive at all and just live with the slightly slower speeds.  Many users do this and have no complaints about transfer speeds.  How fast is 'fast enough' is different for every user.

 

Secondly, running a RAID1 on your parity drive also does nothing to add additional protection to your data.  When a drive fails, every other drive is equally important in reconstructing the contents of the failed drive.  Running RAID1 on your parity drive will add extra protection to that particular drive, but it won't help you at all if you happen to have two data drives die at once.  The only way to truly add extra protection to your array would be to run RAID1 on every single drive, regardless of its role as a parity or data drive.  This is of course completely impractical.  At this point you might as well be running RAID10.

 

Oops meant to say cache drive in that openIing para - not parity drive! No wonder it seemed completely off the mark....corrected!

[Rajahal]

Ah, OK, that makes far more sense.

[Ice_Black]

Which Drive do you recommend for very fast performance and quiet?

 

 

[GoZags]

Which Drive do you recommend for very fast performance and quiet?

 

 

 

I have a bunch of 80gb wd raptor drives (10k) and those were doing sustained writes at 100mb+ from 7200 rpm clients over GBe.  Those particular drives are small, but fast and quiet.  In my case (pun intended) the other drives, fans, etc all add up to so much noise that a quieter drive wouldn't make that much difference 

 

 

I am finally going to get my data onto my unRAID (TB's of data currently on other HDD's and DVD's) and I was wondering if this would work:

 

I have a PCI card coming that does RAID 0, it just runs 2 drives but if I put 2 80gb 10k raptors in a RAID 0 will unraid see that as 160gb?  That as a cache setup for my initial data copy would work to 'speed' it up for me. 

 

1) if I copy, say, 340gb of data in an evening to a share will it stop at 160gb of cache and then write that at 3:40am? What happens to the extra data?  I would just 'drag and drop' and walk away for the evening.

2) could I set the cache copy script to run multiple times a day on a schedule?  What about the script running while the drive is being written too?  I figure there would be slow down, but I wonder if it could be copying to the storage drives while taking on new data?

3) an 80gb (or 160 if I can do RAID 0) would be great as a cache drive for my daily use... perfect actually. BUT I am looking to give a kick to my initial data loading...

Any suggestions?

 

[Rajahal]

Which Drive do you recommend for very fast performance and quiet?

 

 

 

Any SSD will meet those criteria.  With the cache drive, the bottleneck you often run into is the LAN speed, so even the fastest SSD won't necessarily be better than a budget one.  Don't expect more than about 70 - 90 mb/s write speeds across the network.

[BRiT]

I have a PCI card coming that does RAID 0, it just runs 2 drives but if I put 2 80gb 10k raptors in a RAID 0 will unraid see that as 160gb?

 

unRAID will only see it as 160GB if it is a TRUE HARDWARE RAID-0 card. If it needs any level of support from the OS, such as special drivers, then all bets are off.

 

From my experience with my old 74GB 10K RPM WD Raptors, they were outperformed by newer 2TB 7200 RPM SATA drives for the tasks I perform daily. The data density on those ancient (by today's standards) Raptors sucks in comparison.

 

Also, since you're hanging them off the PCI-bus, the fastest theoretical speed you will ever see from them for local operations not going across the network is 133 MB/s. Even if you had a giant RAM-based drives plugged into that RAID card, you will not see more than 133 MB/s. You are limited by the ancient PCI-bus.

[Darts]

Hello!

 

I'm using my unRAID tower "on demand" it does not run 24/7.

How will the cache drive be handeled?

Should I run the move script manually or will it be triggered by the powerdown function (button pressed on the machine itself or on the webinterface).

Maybe the best thing to do would be to leave it on during one night a week?

 

What do you think?

[Joe L.]

Hello!

 

I'm using my unRAID tower "on demand" it does not run 24/7.

How will the cache drive be handeled?

Should I run the move script manually or will it be triggered by the powerdown function (button pressed on the machine itself or on the webinterface).

Maybe the best thing to do would be to leave it on during one night a week?

 

What do you think?

Or not use a cache drive, or if you do, change the mover schedule to run during the times when the server is on.  (You can set it to run at any time, even hourly if you desire.)

[Darts]

Hourly seems nice

 

What happens if  I powerdown the server during a move operation?

[Joe L.]

Hourly seems nice

 

What happens if  I powerdown the server during a move operation?

the partially moved file will exist.

[Darts]

And the move will resume at next powerup and hourly move?

[GoZags]

I have a PCI card coming that does RAID 0, it just runs 2 drives but if I put 2 80gb 10k raptors in a RAID 0 will unraid see that as 160gb?

 

unRAID will only see it as 160GB if it is a TRUE HARDWARE RAID-0 card. If it needs any level of support from the OS, such as special drivers, then all bets are off.

 

From my experience with my old 74GB 10K RPM WD Raptors, they were outperformed by newer 2TB 7200 RPM SATA drives for the tasks I perform daily. The data density on those ancient (by today's standards) Raptors sucks in comparison.

 

Also, since you're hanging them off the PCI-bus, the fastest theoretical speed you will ever see from them for local operations not going across the network is 133 MB/s. Even if you had a giant RAM-based drives plugged into that RAID card, you will not see more than 133 MB/s. You are limited by the ancient PCI-bus.

 

Thanks for the tip BRiT, I might give it a shot for the initial data loading, since I have the 80GB drives already.  If I find I need the cache drive after the initial data load I can look into a 2TB 7200 drive.

[Compass]

I'm thinking about adding a cache drive, however on my 'shares' tab, I don't have the option of 'cache=yes' under each of my 'user shares'. Does the 'cache=yes' option only show up if I've assigned a 'cache device' on the devices page?

 

I'm on Unraid Server Plus 4.7

 

Sorry dumb question but I cant find an answer.

[prostuff1]

Does the 'cache=yes' option only show up if I've assigned a 'cache device' on the devices page?

Yes

[Compass]

Does the 'cache=yes' option only show up if I've assigned a 'cache device' on the devices page?

Yes

 

Thanks

[defected07]

In regards to Compass' request, has it yet been implemented to add scripts to the startup/shutdown process (besides the 'go' script for the startup), so that it either scans a directory (much like a cron.daily directory) to run various scripts (e.g. Subsonic copy from memory to server script) before doing a shutdown/restart?

[Darts]

And the move will resume at next powerup and hourly move?

 

Does anyone know?

[prostuff1]

And the move will resume at next powerup and hourly move?

 

Does anyone know?

I do not think it will

[Joe L.]

And the move will resume at next powerup and hourly move?

 

Does anyone know?

I do not think it will

Since the mover uses rsync, I think it will.  The partially written file on the data disk will be a different size than the one on the cache drive and the one on the cache drive will still be there, therefore, the mover should try to move it.

[prostuff1]

And the move will resume at next powerup and hourly move?

 

Does anyone know?

I do not think it will

Since the mover uses rsync, I think it will.  The partially written file on the data disk will be a different size than the one on the cache drive and the one on the cache drive will still be there, therefore, the mover should try to move it.

 

but on the next power up?  I fully expect the mover to "correct" what was written if it is wrong, but not on the next powerup.  It will only run at the designated time AFTER the next powerup.

[Joe L.]

And the move will resume at next powerup and hourly move?

 

Does anyone know?

I do not think it will

Since the mover uses rsync, I think it will.  The partially written file on the data disk will be a different size than the one on the cache drive and the one on the cache drive will still be there, therefore, the mover should try to move it.

 

but on the next power up?  I fully expect the mover to "correct" what was written if it is wrong, but not on the next powerup.  It will only run at the designated time AFTER the next powerup.

Exactly right...

 

but he had asked if it would be moved "at next powerup and hourly move?" 

 

Nothing will move until the next run of the "mover" script.

[prostuff1]

Exactly right...

 

but he had asked if it would be moved "at next powerup and hourly move?"   

 

Nothing will move until the next run of the "mover" script.

I will give you that.  I think we just read the sentence slightly differently.  You or I were putting the emPAHsis on the wrong sylLABle somewhere in the sentence.