This is my drive line-up

 

3 - 3tb

3 - 2tb

5 - 1.5tb green

4 - 1tb

 

I know from reading I should use one of the 3tb for parity but should I use a 3tb for cache or the 1tb ? It seems like it would be a waste to use a large drive for cache, or should it be hanging around in case the parity drive fails?

 

Personally, I'd just use an older 1T drive and quickly order a new 3T if any of the array drives failed.

Use the smalles one.. but even 1TB is WAY to big unless you do some extreme stuff.. I am using a 120gig ssd and that -never- fills up... Remember that the cache drive is dumped (standard) to the array once a day so you would need to move more then 120gb per day for that to be to small..

Okay, that was my first instinct was to use the smallest fastest drive but I read somewhere on here about using the largest. I will go with a smaller drive then.

The largest drive needs to be the parity drive, that was probably the mixup.

The only reason to use the largest for cache is if you are treating your cache drive as a warm spare.  Then if you have an array drive die you could quickly switch to using it instead since it would match your parity drive.  I personally wouldn't bother.  Just do that as a cold - but precleared - spare.  If your like me and have two unRAID servers you could use the same cold spare as a replacement for either.  I don't want to wait for a new drive to be delivered and I always end up with a drive failing when I have no funds to buy a replacement.  So I've gone to the cold spare idea so that I can buy drives when I have the funds.

If you have the means, personally I would get a cheap 60GB SSD to use as the cache drive.  Not sure why you would need more space than that, but I'm sure people have their reasons.

 

The only reason to use the largest for cache is if you are treating your cache drive as a warm spare.  Then if you have an array drive die you could quickly switch to using it instead since it would match your parity drive.  I personally wouldn't bother.  Just do that as a cold - but precleared - spare.  If your like me and have two unRAID servers you could use the same cold spare as a replacement for either.  I don't want to wait for a new drive to be delivered and I always end up with a drive failing when I have no funds to buy a replacement.  So I've gone to the cold spare idea so that I can buy drives when I have the funds.

 

I like the idea of having a pre-cleared cold spare ready to go in the event of a crash.  I recently had a drive go bad and my array was for the most part offline or unusable for 4 days while I waited for the new drive to arrive and then pre-cleared it.

If you have the means, personally I would get a cheap 60GB SSD to use as the cache drive.  Not sure why you would need more space than that, but I'm sure people have their reasons.

 

The only reason to use the largest for cache is if you are treating your cache drive as a warm spare.  Then if you have an array drive die you could quickly switch to using it instead since it would match your parity drive.  I personally wouldn't bother.  Just do that as a cold - but precleared - spare.  If your like me and have two unRAID servers you could use the same cold spare as a replacement for either.  I don't want to wait for a new drive to be delivered and I always end up with a drive failing when I have no funds to buy a replacement.  So I've gone to the cold spare idea so that I can buy drives when I have the funds.

 

I like the idea of having a pre-cleared cold spare ready to go in the event of a crash.  I recently had a drive go bad and my array was for the most part offline or unusable for 4 days while I waited for the new drive to arrive and then pre-cleared it.

 

I'd say 120/128 rather than 60 to be safe. If you decide to run any plugins to manage your media libraries that space could quickly shrink. My XBMC library data with 900 movies and 135 TV shows (4400 episodes) is almost 8GB. Double that for the Plex library to ~16GB. Throw in your databases for SAB, CP, SB, etc and you looking at another 2GB or so. Subtract that from the ~53GB thats usable on a 60GB SSD and suddenly you don't have enough room to store a blurry ISO or a couple recencoded 1080p movies.

I'd say 120/128 rather than 60 to be safe. If you decide to run any plugins to manage your media libraries that space could quickly shrink. My XBMC library data with 900 movies and 135 TV shows (4400 episodes) is almost 8GB. Double that for the Plex library to ~16GB. Throw in your databases for SAB, CP, SB, etc and you looking at another 2GB or so. Subtract that from the ~53GB thats usable on a 60GB SSD and suddenly you don't have enough room to store a blurry ISO or a couple recencoded 1080p movies.

Certainly if cost is not an issue, go for 120GB+ SSD, but 60GB would suffice if you don't enable the cache drive for shares that may hold large files such as movies.  I use a 120GB SSD cache drive and only enable the cache disk on shares where I store small documents.  If I'm copying huge video files, I'd rather they just immediately go where I want them to be than wait for the mover, but that's just me.

I'd say 120/128 rather than 60 to be safe. If you decide to run any plugins to manage your media libraries that space could quickly shrink. My XBMC library data with 900 movies and 135 TV shows (4400 episodes) is almost 8GB. Double that for the Plex library to ~16GB. Throw in your databases for SAB, CP, SB, etc and you looking at another 2GB or so. Subtract that from the ~53GB thats usable on a 60GB SSD and suddenly you don't have enough room to store a blurry ISO or a couple recencoded 1080p movies.

Certainly if cost is not an issue, go for 120GB+ SSD, but 60GB would suffice if you don't enable the cache drive for shares that may hold large files such as movies.  I use a 120GB SSD cache drive and only enable the cache disk on shares where I store small documents.  If I'm copying huge video files, I'd rather they just immediately go where I want them to be than wait for the mover, but that's just me.

 

Makes allot of sense.

 

Also, if you are going to run APPS on your cache drive, that means there could be a fair amount of data that never gets moved off the cache drive. In that case, there will be limited amounts of cells to be used for writes, thus leading towards the drives limited life write cycles.

 

I.E. if I have a 60B drive with 20-30GB of data that stays there, that's only 30GB of space to use for temporary writes. These cells will be used over and over again while the other cells sit idle.

 

From what I read in the past it was recommended to leave a fair amount of unused space on an SSD for writes, rewrites and cells that may be taken off line.

 

I had an XP instance on an OCZ 60GB Turbo. After about 10 months about 20% of the drive was unusable due to cells being taken offline.

 

It also matters how good the garbage collection is.  I'm not sure if it will kick in on an unRAID cache. Food for thought, I would love to hear someone's experience with that.

Also...

 

Think wisely on what you use the cache drive for... Apps can also very easily be stored on an array drive. people use cache drive to prevent a lot of disks spinning up but you could also just create a regular "apps" share in your array and limit that share to one? disk. That will give you the same effect and also gives you parity protection...

 

You can even use an ssd for that purpose, just make sure to exclude it from all other shares.

 

Sent from my iPad using Tapatalk HD

Also...

 

Think wisely on what you use the cache drive for... Apps can also very easily be stored on an array drive. people use cache drive to prevent a lot of disks spinning up but you could also just create a regular "apps" share in your array and limit that share to one? disk. That will give you the same effect and also gives you parity protection...

 

You can even use an ssd for that purpose, just make sure to exclude it from all other shares.

 

Sent from my iPad using Tapatalk HD

 

 

Adding an SSD as a disk with one share that only stores app would make sense. But I wouldn't do it to a spinner. Plex for instance, never let's the disk spin down.

 

Actually if you have an SSD it makes for sense to use it for that purpose as an apps only array disk than as a cache drive since at this point network speeds are more likely to limit transfer speed than a spinner is. And the apps disk is mostly going to read as opposed to written to.

Yup... Everybody is using the cache drive as an apps drive but there is no real reason for it... an SSD as array drive with single apps share is actually a much better idea.. 

Yup... Everybody is using the cache drive as an apps drive but there is no real reason for it... an SSD as array drive with single apps share is actually a much better idea..

 

I use the cache drive exclusively for APPs (not for making writing faster).

This way my server completely spins down during most of the day except the cache drive while

 

It depends which APPs you have.

I have utorrent as an APP and the download folders are also on the cache.

If I were to use the cache drive as an array drive with single APP share then my parity drive would also be continuously spinning while I was downloading files.

 

Additionally I have VirtualBox with a Windows 7 VM also running off of the cache drive.

This also prevents the cache drive from spinning down and would also potentially use the parity drive if moved to an array drive.

 

Ofcourse that would work. But I often see the remark "that way my array completely spins down".

 

Unraid will spin down individual disks, so if you put that one disk you now use for apps in the array, then all disks will be spun down besides that one apps dir.

 

So the number of disks spinning will be the whether you save apps on cachedrive or on an array drive.. Added benefit of using an array drive is that the apps drive will be parity protected..

Ofcourse that would work. But I often see the remark "that way my array completely spins down".

 

Unraid will spin down individual disks, so if you put that one disk you now use for apps in the array, then all disks will be spun down besides that one apps dir.

 

So the number of disks spinning will be the whether you save apps on cachedrive or on an array drive.. Added benefit of using an array drive is that the apps drive will be parity protected..

 

Number of disks spinning will be +1 higher if array disk is used - parity disk will also be spinning in addition to the APPs disk. In my system which has 1 parity, 4 data, 1 cache - it is a difference between 1/6 and 2/6 spinning

 

My APPs are constantly writing to the cache drive. If using a parity protected disk for APPs it will strain the parity disk way beyond regular use and it could potentially slow down data writes when intensively used by the APPs.

 

I backup data from the cache drive - specifically APPs settings and the VM. Anything else (currently downloading torrents) can be restored easily if a cache drive crash occurs.

 

This is where SSD's can make a lot of sense for cache/apps drives.  You don't care about spindown because:

 

a) they don't spin and

b) they are lucky to use 2w of power

This is where SSD's can make a lot of sense for cache/apps drives.  You don't care about spindown because:

 

a) they don't spin and

b) they are lucky to use 2w of power

 

I don't care about the APPs disk spinning down (it is a given for me that it is always spinning), I just don't want the parity drive to also be constantly spinning and worse even in use (writing).

 

Ofcourse that would work. But I often see the remark "that way my array completely spins down".

 

Unraid will spin down individual disks, so if you put that one disk you now use for apps in the array, then all disks will be spun down besides that one apps dir.

 

So the number of disks spinning will be the whether you save apps on cachedrive or on an array drive.. Added benefit of using an array drive is that the apps drive will be parity protected..

 

Number of disks spinning will be +1 higher if array disk is used - parity disk will also be spinning in addition to the APPs disk. In my system which has 1 parity, 4 data, 1 cache - it is a difference between 1/6 and 2/6 spinning

 

My APPs are constantly writing to the cache drive. If using a parity protected disk for APPs it will strain the parity disk way beyond regular use and it could potentially slow down data writes when intensively used by the APPs.

 

I backup data from the cache drive - specifically APPs settings and the VM. Anything else (currently downloading torrents) can be restored easily if a cache drive crash occurs.

 

Actually, that is not completely true.. If you use a cache drive (for caching) then you can enable the cache drive for that APPS directory that is limited to one drive... That way:

 

- all drives are spun down besides the APPS drive and the cache drive (parity drive is also spun down since the cache drive is used);

- APPS drive will be parity protected

 

Ofcourse you still have two drives spun up; apps and cache, so your +1 comment is still valid..

My APPs are constantly writing to the cache drive. If using a parity protected disk for APPs it will strain the parity disk way beyond regular use and it could potentially slow down data writes when intensively used by the APPs.

 

Forgive me for laughing a little.. but "strain" 

 

unRAID is great for many people as it saves heat, power, wear and tear on having a huge number of drives spinning.  Having two drives spinning for your applications is not really a strain.

 

Over the course of many years, I've always had somewhere from 4-8 drives, spinning 24x7x365 without issues beyond the normal drive failure. Some drives have lasted 2-3 years (maxtor p-ata days gone by) and some have outlived the 5 year warranty. 

 

Before unRAID I've always had RAID1 on at least 4 sets of drives that were spinning until death.

 

unRAID is cool, but it tends to give us all a lil OCD at times. 

 

Now what you will have, and I agree with it, is a partial choking of maximum write speed to your array.

Speaking frankly,  I've had hundreds of torrents on a parity protected apps drive back when the WD EACS 1TB drives were all the rage.  It was slow but it worked well.  Once I upgraded to the EADS drives it got better, then upgraded to a 1.5TB 7200 RPM drive for the apps and parity it was even better. minimal choking.

 

I eventually upgraded to a RAID1 cache/RAID0 Hybrid on an Areca using those 1.5tb 7200 RPM drives.

These drives were spinning 24x7x365 until hurricane sandy.

 

Point being, do what works for you. If the drive is going to fail, it's not going to fail due to undue strain. Drives are designed to work.

Didn't someone on this forum prove that it's actually worse on your drives to have them constantly spinning up and down versus just letting them spin 24/7?  I know I've always let my drives spin 24/7 (minus a short period where I experimented with letting them spin down and quickly got annoyed by the wait time for them to spin up when I wanted to access).  I've got some drives that have been going 5+ years...did have a few go on me (mostly the WD EARS drives).

Didn't someone on this forum prove that it's actually worse on your drives to have them constantly spinning up and down versus just letting them spin 24/7?  I know I've always let my drives spin 24/7 (minus a short period where I experimented with letting them spin down and quickly got annoyed by the wait time for them to spin up when I wanted to access).  I've got some drives that have been going 5+ years...did have a few go on me (mostly the WD EARS drives).

 

There are arguments on both sides of the fence. I'll add an "it depends".

 

For drives I access often.  My download folder, my /home folders, Source code, email, cache, parity, etc, etc.

I leave them spinning all the time, or at least for 1/2 the day on some of them.

 

For drives I access, but not when at home. "Music."  I spin them down after 2 hours or so.

 

For drives I do not access often.  "Movies."  I spin them down after an hour.

These drives will spin up "at least" 2x a month. Once for each drive to do a bad blocks and an index of all files on the hard drive.  Once for a monthly parity check.  Possibly more if I add files and reindex the list of files on the drive.

 

Most of the drive failures on my unRAID array have been due to hardware (sata cables) or shutdown issues. Sometimes the shutdown will not go well and I think as I powered off the machine, it caused issues on the format of the platter.  Usually I was able to recover.

 

What intrigued me about unRAID was having these data drives shutdown, lack of striping, self contained filesystems per drive and the OS is on a RAM drive, thus one less set of drives(raid1) spinning.  I'm considering use of this concept in other areas.

 

In summary, for a busy drive, it's best to leave it spinning or create a longer spindown timer. I had a cron job that would run all the time, and between certain hours, trigger a read or write to specific disks.  This way I could have a 1 hour spin down, but for the 12 hours I was awake, Specific drives would always be spinning.

 

I never had a failure or undue strain.

An SSD in the array will still require spinning the parity drive for every write to it.....

 

The OP has a bunch of old drives. Why buy a new SSD when he can just stick one of them in as the cache?

LOL... this whole thing is turning into a discussion when it was meant as a diffent view on things.. Everyone should do what they like.

 

But as a final answer: "why would you have a disk in the array when you cal also have it outside of the array and not spinning up the parity drive"" ?

 

Because of the fact data is protected by parity then.

I have a cache drive for two reason the first being the network timeout issue in trying to write large iso images to the protected array ie 40Gb files.  The second is that it has my apps on it,  if the apps are stored on an ssd that is part of the array when apps are unpacking etc etc they can affect read performance of the iso files back out through my media players.  Also it means I only ever have 1 drive left running instead of 2.  Besides my apps are not critical as far as I'm concerned I backup the info there every week or so.