dboonthego

If your replacements aren't bigger than 6TB then it really doesn't matter. I would probably do the data disk first.

On one hand you're saying you want to copy to the cache temp video folder and then have mover move those to array, but on the other hand you're saying you want to have the mover move those files back to cache? The mover is one direction. Also, there is no mover on a cache-only share, but I think I know what you meant. This is the old terminology of "prefer." Use this if you primarily want the files to reside on the cache. New files are written to the cache, and you want them to stay on the cache. If the cache gets full, then new files go on the array. The mover will move them back to cache when space is available. This is the old terminology of "Yes." Use this if you primarily want files to reside on the array but want to take advantage of the cache disk for faster write speeds. The mover will move files from the cache to the array. This is what you said you wanted.

SSH is still available with array stopped.

You do it like this: Primary Storage = Cache Secondary Storage = Array Mover Action=Cache --> Array

You probably would have received a link if you just asked. Remember, people are volunteering their time to try to help you; a positive attitude goes a long way. The manual is at docs.unraid.net and is laid out rather well. Follow these clicks: Unraid OS > Manual > Storage Management > Replacing disks > Rebuilding a drive onto itself

Basically, your friend purchased this and gave a license to you. It's frowned upon. I'm not sure if Limetech will transfer the registration.

Files amongst your shares can be spread across multiple disks. It's normal to have the share folder on multiple disks, but the abnormal part is having the same filename in the same directory on two or more disks. There are several reasons why this can happen; moving files from disk to disk is one of them. If the files are copied to destination, but not removed from source, you have a duplicate situation. Unraid fetches your files from the array disks and shows them to you as if they are in one spot. Your SMB share can only contain unique filenames so if duplicates are encountered, Unraid picks one to return; probably lowest disk#. It's the same reason why you cannot have duplicate file names in the same directory on your Windows system. Reading or writing to a duplicate file may also spin up those other disks and parity. When one spins down another might spin up because the file exists there too. It's weird behavior and the resolution is to make sure there are 0 duplicates across your array.

Normal stuff, not the issue. The dupeGuru docker might be a good option for you. It may or may not be easy to determine yourself if you have duplicates or where they exist. Considering you've used unBalance to shift files around, there's a good chance you have duplicates somewhere. All it takes is one to cause this. You can poke around your disks to compare. Go to shares > disk shares > diskX -> Export=Yes to enable disk level shares. Just be careful not to copy files between disk and user shares and perhaps set Export=No when you're done. No single file should exist in the same location between two disks. You will need to determine which file to keep as these are duplicate file names, but binary content could be different. You can test how it works yourself. Create a text file called dupetest.txt. Edit the contents to something like "This file is located on disk1" and save it to a share on disk1. Copy the file to the same location on disk2 and edit its contents to "This file is located on disk2" and save it. Now browse to \\tower\share\dupetest.txt and open it. Unraid will serve you one of the two versions. Now, delete it and it will seem like the file did not delete. If you open it again, it will be the other version. Delete it again and the file is gone.

They're not USB, but coincidentally, they spun down on their own eventually. The orb works, but I couldn't find a UD setting to control it automatically. I have 3 unassigned disks. None are mounted; two are zeroed. They were consistently green, and I was puzzled why. Thanks.

A common reason is having duplicate files on multiple disks of the same share name. These shares are configured to write directly to the array and if you have any duplicates in there, it will spin up all drives. A------s shareUseCache="no" # Share exists on disk1, disk2 B-----s shareUseCache="no" # Share exists on disk1, disk2 E----s shareUseCache="no" # Share exists on disk1, disk2 H--------a shareUseCache="no" # Share exists on disk1, disk2 M-----e shareUseCache="no" # Share exists on disk1, disk2 P-------s shareUseCache="no" # Share exists on disk1, disk2 P----s shareUseCache="no" # Share exists on disk1, disk2 V----s shareUseCache="no" # Share exists on disk1, disk2

Am I understanding this to mean UD spin down follows Unraid's disk spin down setting? I seem to notice opposite effect where UD disks don't spin down. My Unraid disk spin down setting is 1 hour.

Windows has this feature built-in.

To avoid extra power plugs and usb cords, I installed a 5.25 to 3.5 swappable drive bay. The drive can be removed and installed in seconds. I have two disks; one in the bay as unassigned device and the other is kept off-site. They are rotated occasionally. I just use rsync to perform a backup of each array disk to a diskX folder on the backup drive although I hear lucky backup is a good docker based backup solution.

I assumed yours had the default name of Cache. Yours is named plexer. In the appdata share settings, can you select plexer for primary storage? Primary storage (for new files and folders): plexer Secondary storage: None

Thanks. The docs procedure implies using maintenance mode gives better performance but, isn't necessarily crucial for maintaining parity during a disk clear.

It wasn't in maintenance mode, but docker and VMs were stopped, and nothing was being written to the array. Maintenance mode is a suggestion, correct?

Last month's parity sync completed with 0 errors. Since then, I've installed a new disk and SATA controller. The disk is an unassigned device and is the only disk connected to the controller. I cancelled this month's parity sync 3 minutes in because I was planning to zero and remove some smaller disks. I zeroed two disks (4 & 5) using the dd method. Each was zeroed one at a time. Once completed, I stopped the array, performed a new config, preserved all assignments, set disk 4 and 5 unassigned, clicked parity is valid and started the array. I started a manual parity sync. When it completed, it reported 3 errors. I'll re-run another parity sync, but any thoughts on possible cause? This is first parity error on this server. dd bs=1M if=/dev/zero of=/dev/md4p1 status=progress dd bs=1M if=/dev/zero of=/dev/md5p1 status=progress

Looks like a problem with the cache. Reboot and run a filesystem check on the cache.

You're zeroing the disk including the partition table so probably isn't necessary to do, but yes, that stops new writes to the excluded disk.

If the folder is empty, yes. If not, you can copy files to the cache's appdata folder. Once appdata has been removed from the data disks, it will stop spinning them up. You can modify your appdata share settings and set primary storage to Cache and secondary storage to None. This will prevent new files in this share from being written to the array.

Your appdata folder exists on disks 1-4 and those disks including parity will spin up on every write to the appdata share. You'll need to move the appdata folder off of the array disks to resolve.

Is this a new USB you recently created, or was it a working USB that stopped booting?

You can choose to export disk shares which allows you to browse individual disks in file explorer. There's no native search capability in the GUI. I'm sure there's a docker out there that can catalog your files.

Yes, install the replacement it will rebuild from the pool partner. Install the disk and assign it to the parity slot. The only requirement is you must use a disk size which equal or larger than any of the data disks in the array (not pools).

I followed the same steps and did not experience the same behavior you and the other guy did. When I shut down in step5, I simply powered back up. I didn't physically change any disks as I already had them connected. Most people don't have a warm spare ready which is probably why it's written to shutdown. Not sure what caused this, but I highly doubt it's related to step5.