dboonthego

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.

As I understand it, you performed a New Config and flipped parity and disk1 while also unassigning disk7? Then started the array and noticed your mistake, and stopped it? You would have seen a notice on parity disk showing "All existing data on this device will be OVERWRITTEN when array is Started" which you likely overlooked expecting you had set the parity correctly. What is the status of Disk7? Is it truly failed, or you did you simply see an X after unassigning it? The way I see it... Parity is fine. Disk1 is toast Disks 2-6 are fine. Disk7 is questionable. (This is disk you tried to shrink) Your original parity is based on having disks 1-7. *If* disk7 can be mounted and has no read errors, I'm thinking you can rebuild your disk1 like this.. Do another new config. This time making sure you get it right. Assign everything back to your original config... Assign disks 1-7 making sure you put original parity in parity slot. ^^ You can assign your newly purchased 14TB as disk1 (keeping original disk1 in-tact for possible recovery) Click the tick box that says parity is already valid. Start the array. Disk1 should be unmountable, DO NOT FORMAT IT. Stop the array. Unassign Disk1. Start the array. Disk 1 is Disabled. Stop the array. Assign Disk1. Start array to rebuild disk1 from parity. This of course requires that Disk 7 is in good shape and you didn't otherwise mess with your orig parity disk. Please have someone else on this forum confirm these steps are good before attempting.

I'm slightly confused. Were you trying to make your array smaller by removing disk1 and 14TB of space? Or did disk1 fail and you followed the shrink array procedure to rebuild it? What steps did you follow exactly? Right now, parity is invalid and disk1 is missing.

I use two SSDs in Raid1 (mirror) configuration for my cache pool.

Well, what are you waiting for??? Yes, you can have multiple separate pools. In your case, you have two disks so you could have one pool of two disks or two pools with one disk. Just setup how you want. For example: Give this a read: https://docs.unraid.net/unraid-os/manual/storage-management/#why-use-a-pool

By "procedure" you're referring to the actual parity copy or data disk rebuild and not the documented procedure, right? Shutting down (step5) after unassigning the data disk to add new larger parity is fine.

I ran through a test yesterday and also shutdown simply because I followed the steps. Difference for me was I already had an unassigned disk larger than parity in the system and didn't physically alter the hardware. I had no issue performing the parity swap/data rebuild.

Yep. I try to copy then delete now as move can have grim results even when you're careful.

First, do you have backups? Second, do not format anything. Third, get a second opinion before you act. The parity disk itself is likely fine, but parity may not be valid at this point and you are reauired to rebuild. Disk2 does not have a valid file system because the re-build encountered parity errors and never completed. I would put the original disk2 back in service and rebuild parity. This should get you back to where you were before attempting the disk2 rebuild. 1. Take a screen shot of your disk assignments. 2. Power down 3. lnstall original disk2 4. Power up 5. Go to Tools->New configuration. 6. On main tab, assign your disks exactly how they were before, except substituting your original disk2. MAKE CERTAIN YOU ASSIGN PARITY CORRECTLY. DO NOT ASSIGN A DATA DISK TO PARITY SLOT. 7. Start array. 8. Wait for parity to sync to complete.

Is this the *new* 4TB disk you were trying to rebuild as disk2? WDC_WD40EFRX-68N32N0_WD-WCC7K5HTV05L Parity is disabled due to error and disk2 is invalid because it hasn't rebuilt yet. I would try re-seating your drive connections. Since you were just replacing a drive, there's a good chance it has a bad connection. Post back if that doesn't work. Worst case, you always have your original disk2 and a new 4TB you can use to rebuild parity.