Hi -

 

Sorry, these are probably pretty basic questions, but here goes:

 

• Can I run 6 data drives on a Plus license if I forgo a cache drive?  It doesn't look like it, but I thought I'd ask.
  
• I'm running a cache drive now.  Since this is feature of the array, is the cache drive protected by the array?  I.e., if it fails can I rebuild normally?  I don't think so, but again thought I'd ask.
  
• Finally, my primary reason for running a cache drive is to support Plex.  I'd like to be able to back up the /apps directory.  If the cache drive is not protected by the array, and I want to backup my /apps to the array, am I better off running /apps on the cache drive or on a drive outside the array?
  

 

FYI, I'm running 5.05 but planning to upgrade to 6b6 or 6b7 soon.

 

Thanks

Only 5 data drives are available for a plus license. The cache drive is not considered a data drive. The cache drive speeds up writes because it is not protected by parity and so parity is not updated when cache is written to. Cached share writes are moved to the array at a later time, and so not only is the data on cache not protected, but any share data that is cached is also not protected until it is moved to the array.

Thanks.  I know there are some threads on stopping and backing up application data, I'll go dig for them.  On the last question, though - given that I'd like to backup my application data to the array, is it better to locate that data on the cache drive or outside the array?

Thanks.  I know there are some threads on stopping and backing up application data, I'll go dig for them.  On the last question, though - given that I'd like to backup my application data to the array, is it better to locate that data on the cache drive or outside the array?

I can't think of any obvious and necessary differences between the two scenarios. If you were backing them up to a different computer then it would be slightly simpler to access the cache drive over SMB for example, but even that can be done.

Some of the best practices that have evolved over the years of unraid are in need of re-evaluation. The primary reason most often stated to use a cache drive is to speed up transfers to the array, and to run apps without having 2 drives constantly spinning. The speed issue is almost gone with the latest hardware, even writing to the parity protected array can be almost as quick as to a cache drive, and you gain instant parity protection. The issue of having the parity drive constantly spun up is still here, but for some use cases it's really not worth dealing with a cache drive just to avoid a single extra drive spinning.

 

In your case, would it be so bad to leave everything including Plex on the parity protected array? You would still need to do periodic backups, because unraid isn't a backup by itself, but you gain the ability to have 1 drive fail without losing stuff.

To your point, I've been evaluating the cache drive and come to the conclusion that I don't need it for its intended purpose - speeding up writes to unRAID.  Writes to the parity protected array aren't that fast, but they are fast enough for my purposes.

 

I could locate Plex on the array, but I'd prefer not to.  I can use older, cast off drives for the app drive so I don't care that much that Plex keeps them spinning.  I'd prefer not to put the cycles on the more valuable assets, i.e. the NAS drives.  Also, my personal approach to this unRAID array is that it *is* the backup - in other words I have the source data elsewhere and back it up to unRAID.  To be consistent with that approach I'd just as soon have the data on an app drive and back it up to the array.  The only question is - cache drive or drive external to the array for application data, given the primary use case where I want to backup the application data to the array.

The only question is - cache drive or drive external to the array for application data, given the primary use case where I want to backup the application data to the array.

 

Install your app drive as a cache drive in unRaid, since that is the easiest way.

 

The main reason people (including myself) were installing their apps on a drive external to the unRaid array was because we are using SSD drives, and the ReiserFS doesn't support TRIM.  By installing outside of unRaid, we could format the SSD drive as EXT4, which does support TRIM.

 

Look at this topic for a way to maintain backups of your app configs:

http://lime-technology.com/forum/index.php?topic=31246.msg282114#msg282114

 

 

The main reason people (including myself) were installing their apps on a drive external to the unRaid array was because we are using SSD drives, and the ReiserFS doesn't support TRIM.  By installing outside of unRaid, we could format the SSD drive as EXT4, which does support TRIM.

 

 

Is that concern now obviated given the BTRFS-formatted cache drives in unRAID 6b6+?

Is that concern now obviated given the BTRFS-formatted cache drives in unRAID 6b6+?

 

I think I saw something posted that it will be in the next beta release.

In the current beta, the BTRFS formatting and use as a cache drive does not have the option to enable TRIM.

Is that concern now obviated given the BTRFS-formatted cache drives in unRAID 6b6+?

 

I think I saw something posted that it will be in the next beta release.

In the current beta, the BTRFS formatting and use as a cache drive does not have the option to enable TRIM.

But fstrim is included in 6b6, you can run it whenever you wish, and can be scheduled in a cron job.

But fstrim is included in 6b6, you can run it whenever you wish, and can be scheduled in a cron job.

 

Thanks!

 

I had to look up how to do this,  and maybe this will enable others (also) new to this:

 

nano /etc/cron.daily/trim

-=-=-=-

 

#!/bin/sh

LOG=/var/log/trim.log

echo "*** $(date -R) ***" >> $LOG

fstrim -v /mnt/cache/  >> $LOG

 

-=-=-=-

 

chmod +x /etc/cron.daily/trim

 

source:  http://turriebuntu.wordpress.com/ubuntu-pages/precise-specific-pages/using-fstrim-to-trim-your-ssd-instead-of-delete-in-fstab/

 

Dennis

 

EDIT:  Of course you'll have to save this to the /config folder and reload it from the 'go' script to make it persistent. 

 

e.g. add a line like this to your go script:

 

# reload cron jobs

cp -a /boot/config/scripts/trim /etc/cron.daily/

 

/EDIT