New Config option...

[opentoe]

I have removed disk12 out of my array and made it a cache drive. (getting ready to use a docker image on that). Right now the system complains that it is missing a disk and I'm guessing the only option to resolve this and rebuild the array with the new drive setup is to execute that command NEW CONFIG from the tools menu, correct?

 

Also, how do I eliminate writes to the cache? I Clicked on my user shares and dropped down the excluded disk list and didn't see the cache drive there. I want to use the cache drive just as a regular data drive for dockers only.

 

Thanks.

 

[itimpi]

Also, how do I eliminate writes to the cache? I Clicked on my user shares and dropped down the excluded disk list and didn't see the cache drive there. I want to use the cache drive just as a regular data drive for dockers only.

For each of your shares set the Use Cache option to 'No'.  However for any related to dockers you probably want them set to 'Only'.

[trurl]

I have removed disk12 out of my array and made it a cache drive. (getting ready to use a docker image on that). Right now the system complains that it is missing a disk and I'm guessing the only option to resolve this and rebuild the array with the new drive setup is to execute that command NEW CONFIG from the tools menu, correct?

 

Also, how do I eliminate writes to the cache? I Clicked on my user shares and dropped down the excluded disk list and didn't see the cache drive there. I want to use the cache drive just as a regular data drive for dockers only.

 

Thanks.

Yes, you must do a new config and let it rebuild parity without the removed disk. Make sure you assign your disks correctly.

 

To keep your regular user shares from using cache, set them to Use cache disk: No

 

For your dockers and other apps, create a user share called appdata and set it to Use cache disk: Only

You could call the share something else, but many of the docker templates are preconfigured for /mnt/cache/appdata

 

If you ever decide to do VMs, it is common to put those on cache also. I have a cache-only share named VMs for that.

[opentoe]

Figured it out. Since I never had a cache drive I was never aware there was an option NOT to use the cache drive on the user share settings.

 

Maybe we can request to have ALL settings on all setup areas present and the ones not applicable or able to use just grayed out so we know what we can and cannot do.

[trurl]

Figured it out. Since I never had a cache drive I was never aware there was an option NOT to use the cache drive on the user share settings.

 

Maybe we can request to have ALL settings on all setup areas present and the ones not applicable or able to use just grayed out so we know what we can and cannot do.

Make sure you also set your apps to use a cache-only share or they will break when mover moves them to the array.

[opentoe]

I have removed disk12 out of my array and made it a cache drive. (getting ready to use a docker image on that). Right now the system complains that it is missing a disk and I'm guessing the only option to resolve this and rebuild the array with the new drive setup is to execute that command NEW CONFIG from the tools menu, correct?

 

Also, how do I eliminate writes to the cache? I Clicked on my user shares and dropped down the excluded disk list and didn't see the cache drive there. I want to use the cache drive just as a regular data drive for dockers only.

 

Thanks.

Yes, you must do a new config and let it rebuild parity without the removed disk. Make sure you assign your disks correctly.

 

To keep your regular user shares from using cache, set them to Use cache disk: No

 

For your dockers and other apps, create a user share called appdata and set it to Use cache disk: Only

You could call the share something else, but many of the docker templates are preconfigured for /mnt/cache/appdata

 

If you ever decide to do VMs, it is common to put those on cache also. I have a cache-only share named VMs for that.

 

Awesome. Doing the rebuild parity now. I'm always snapping a screen shot of my drive lists when ever I make changes. Those always come in handy.

 

 

[garycase]

... I'm always snapping a screen shot of my drive lists when ever I make changes. Those always come in handy.

 

Backups of ANY kind are always good to have 

... flash drive, configuration, or whatever.

 

You should periodically copy your entire flash drive to a backup folder on another PC (or the array).  Simple enough to keep an "UnRAID Flash Backups" folder with subfolders named the date of the backup.

 

[SSD]

... I'm always snapping a screen shot of my drive lists when ever I make changes. Those always come in handy.

 

Backups of ANY kind are always good to have 

... flash drive, configuration, or whatever.

 

You should periodically copy your entire flash drive to a backup folder on another PC (or the array).  Simple enough to keep an "UnRAID Flash Backups" folder with subfolders named the date of the backup.

 

There is no problem making a backup, but you have to be careful restoring a backup of the flashdrive.

 

If you have changed your configuration, for example, upsized your parity disk and moved your parity so that it is now a data disk, using the backup of the configuration would result in data loss. Things like the go file and unmenu settings are useful to backup, but some items in the config folder are dangerous. I prefer the method opentoe mentions about taking an occasional screenshot of the unRAID drive config.

[opentoe]

I'm always backing up the flash drive randomly and throwing it on my owncloud VPS, which is also backed up by the VPS hosting company. And of course use a commercial service like box.com or whatever as well.

 

[RobJ]

I'm always backing up the flash drive randomly ...

 

Just keep in mind that after restoring a random backup and booting, it may indicate an unclean shutdown and start a parity check, which you can immediately cancel if unneeded.  It just means you restored a backup that was made while the array was started.

[SSD]

I'm always backing up the flash drive randomly ...

 

Just keep in mind that after restoring a random backup and booting, it may indicate an unclean shutdown and start a parity check, which you can immediately cancel if unneeded.  It just means you restored a backup that was made while the array was started.

 

Yes - but as in the example I gave above, if the backup was taken when you had a different device configuration, and the array was started - the parity check would immediately start clobbering data. By the time you canceled it - you'd have dug a sizable hole and be spending the better part of the next 48 hours trying to recover.

 

Although I do backup my flash from time to time (file backup), I never use one to recover from. I just use it to access prior versions of files that I had stored on my flashdrive - like the go file and samba configuration. For those worried, the most dangerous file in the config directory is the super.dat file. When you make a copy just delete that file and you'll avoid the dangers that I listed.

[trurl]

I always recall the user who got a new parity disk and used his old parity as a data disk. Then sometime later, in an effort to fix some other problem, he restored a backup of his flash. Using that backup unRAID saw his former parity (now data) disk as the parity disk and immediately began a correcting parity check, writing parity to a drive that now had data on it.

[garycase]

Yep ... ANY backup needs to be properly applied.    I always delete all my obsolete flash backups if I've made a configuration change to minimize the possibility of that kind of error.  [i won't say "eliminate", as none of us can guarantee we won't make a mistake like that ... I've know a lot of folks over the years who, after a LONG day of coding, were "cleaning up" their disk and wanted to get a current directory by typing Dir *.*  ... but inadvertently typed Del *.*      Needless to say that's not a good thing!