dboonthego

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.

Is it possible these already exist on another disk in Media? Look in each instance of Media in /mnt/diskX/ and see if you have duplicates.

Do another copy and it will probably resolve itself. I couldn't reproduce the issue for someone else. Did you power down in step5? I don't think it matters, but wondering if you did.

The good ole / slash. Sometimes you don't want it and sometimes you do. I once moved hundreds of files and forgot the trailing slash/ in the destination. Essentially that deleted everything.

We must have been typing same time. Glad it's working. I don't understand what happened. Immediately after copying, the config still acted like nothing happened. Sep 24 07:38:13 Tower emhttpd: copy: disk5 to disk0 completed Sep 24 07:38:30 Tower kernel: md: unRAID driver removed Sep 24 07:38:30 Tower emhttpd: shcmd (423): /sbin/modprobe md-mod super=/boot/config/super.dat Sep 24 07:38:30 Tower kernel: md: unRAID driver 2.9.27 installed Sep 24 07:38:30 Tower emhttpd: Device inventory: Sep 24 07:38:30 Tower emhttpd: HGST_HDN726040ALE614_K4K4X0LB (sdm) 512 7814037168 Sep 24 07:38:30 Tower emhttpd: WDC_WD30EZRX-00D8PB0_WD-WMC4N0E9DET3 (sdj) 512 5860533168 Sep 24 07:38:30 Tower emhttpd: HGST_HDN726040ALE614_K7H4DS5R (sdk) 512 7814037168 Sep 24 07:38:30 Tower emhttpd: ST8000VN004-3CP101_WWZ2NPC9 (sdh) 512 15628053168 Sep 24 07:38:30 Tower emhttpd: HITACHI_HUS724040ALE640_PAH4YGUT (sdg) 512 7814037168 Sep 24 07:38:30 Tower emhttpd: Samsung_SSD_870_EVO_1TB_S75BNS0W540967Z (sdd) 512 1953525168 Sep 24 07:38:30 Tower emhttpd: HITACHI_HUS724040ALE640_PAH4YB7T (sde) 512 7814037168 Sep 24 07:38:30 Tower emhttpd: Samsung_SSD_870_EVO_1TB_S75BNS0W531612Z (sdb) 512 1953525168 Sep 24 07:38:30 Tower emhttpd: Samsung_SSD_870_EVO_1TB_S75BNS0W531603P (sdf) 512 1953525168 Sep 24 07:38:30 Tower emhttpd: WDC_WD30EFRX-68EUZN0_WD-WCC4N5LLPZF2 (sdc) 512 5860533168 Sep 24 07:38:30 Tower emhttpd: WDC_WD30EZRX-00D8PB0_WD-WCC4N2LVT4EH (sdn) 512 5860533168 Sep 24 07:38:30 Tower emhttpd: WDC_WD30EZRX-00SPEB0_WD-WCC4E6YRLU0U (sdo) 512 5860533168 Sep 24 07:38:30 Tower emhttpd: HGST_HDN724030ALE640_PK2234P9KAK5SY (sdl) 512 5860533168 Sep 24 07:38:30 Tower emhttpd: HGST_HDN726040ALE614_K7J8ZU5L (sdi) 512 7814037168 Sep 24 07:38:30 Tower emhttpd: ST8000VN004-3CP101_WWZ2NPDM (sdp) 4096 1953506646 Sep 24 07:38:30 Tower emhttpd: SanDisk_Cruzer_Fit_4C530012451108113053-0:0 (sda) 512 15630336 Sep 24 07:38:30 Tower kernel: mdcmd (1): import 0 sdh 64 7814026532 0 ST8000VN004-3CP101_WWZ2NPC9 Sep 24 07:38:30 Tower kernel: md: import disk0: (sdh) ST8000VN004-3CP101_WWZ2NPC9 size: 7814026532 Sep 24 07:38:30 Tower kernel: md: import_slot: 0 wrong Sep 24 07:38:30 Tower kernel: mdcmd (2): import 1 sdj 64 2930266532 0 WDC_WD30EZRX-00D8PB0_WD-WMC4N0E9DET3 Sep 24 07:38:30 Tower kernel: md: import disk1: (sdj) WDC_WD30EZRX-00D8PB0_WD-WMC4N0E9DET3 size: 2930266532 Sep 24 07:38:30 Tower kernel: mdcmd (3): import 2 sdi 64 3907018532 0 HGST_HDN726040ALE614_K7J8ZU5L Sep 24 07:38:30 Tower kernel: md: import disk2: (sdi) HGST_HDN726040ALE614_K7J8ZU5L size: 3907018532 Sep 24 07:38:30 Tower kernel: mdcmd (4): import 3 sdn 64 2930266532 0 WDC_WD30EZRX-00D8PB0_WD-WCC4N2LVT4EH Sep 24 07:38:30 Tower kernel: md: import disk3: (sdn) WDC_WD30EZRX-00D8PB0_WD-WCC4N2LVT4EH size: 2930266532 Sep 24 07:38:30 Tower kernel: mdcmd (5): import 4 sdo 64 2930266532 0 WDC_WD30EZRX-00SPEB0_WD-WCC4E6YRLU0U Sep 24 07:38:30 Tower kernel: md: import disk4: (sdo) WDC_WD30EZRX-00SPEB0_WD-WCC4E6YRLU0U size: 2930266532 Sep 24 07:38:30 Tower kernel: mdcmd (6): import 5 sdm 64 3907018532 0 HGST_HDN726040ALE614_K4K4X0LB Sep 24 07:38:30 Tower kernel: md: import disk5: (sdm) HGST_HDN726040ALE614_K4K4X0LB size: 3907018532 Sep 24 07:38:30 Tower kernel: md: import_slot: 5 replaced Sep 24 07:38:30 Tower kernel: mdcmd (7): import 6 sdl 64 2930266532 0 HGST_HDN724030ALE640_PK2234P9KAK5SY Sep 24 07:38:30 Tower kernel: md: import disk6: (sdl) HGST_HDN724030ALE640_PK2234P9KAK5SY size: 2930266532 Sep 24 07:38:30 Tower kernel: mdcmd (8): import 7 sdc 64 2930266532 0 WDC_WD30EFRX-68EUZN0_WD-WCC4N5LLPZF2 Sep 24 07:38:30 Tower kernel: md: import disk7: (sdc) WDC_WD30EFRX-68EUZN0_WD-WCC4N5LLPZF2 size: 2930266532 Sep 24 07:38:30 Tower kernel: mdcmd (9): import 8 sdg 64 3907018532 0 HITACHI_HUS724040ALE640_PAH4YGUT Sep 24 07:38:30 Tower kernel: md: import disk8: (sdg) HITACHI_HUS724040ALE640_PAH4YGUT size: 3907018532 Sep 24 07:38:30 Tower kernel: mdcmd (10): import 9 sde 64 3907018532 0 HITACHI_HUS724040ALE640_PAH4YB7T Sep 24 07:38:30 Tower kernel: md: import disk9: (sde) HITACHI_HUS724040ALE640_PAH4YB7T size: 3907018532 Sep 24 07:38:30 Tower kernel: mdcmd (11): import 10 Sep 24 07:38:30 Tower kernel: mdcmd (12): import 11 Sep 24 07:38:30 Tower kernel: mdcmd (13): import 12 Sep 24 07:38:30 Tower kernel: mdcmd (14): import 13 Sep 24 07:38:30 Tower kernel: mdcmd (15): import 14 Sep 24 07:38:30 Tower kernel: mdcmd (16): import 15 Sep 24 07:38:30 Tower kernel: mdcmd (17): import 16 Sep 24 07:38:30 Tower kernel: mdcmd (18): import 17 Sep 24 07:38:30 Tower kernel: mdcmd (19): import 18 Sep 24 07:38:30 Tower kernel: mdcmd (20): import 19 Sep 24 07:38:30 Tower kernel: mdcmd (21): import 20 Sep 24 07:38:30 Tower kernel: mdcmd (22): import 21 Sep 24 07:38:30 Tower kernel: mdcmd (23): import 22 Sep 24 07:38:30 Tower kernel: mdcmd (24): import 23 Sep 24 07:38:30 Tower kernel: mdcmd (25): import 24 Sep 24 07:38:30 Tower kernel: mdcmd (26): import 25 Sep 24 07:38:30 Tower kernel: mdcmd (27): import 26 Sep 24 07:38:30 Tower kernel: mdcmd (28): import 27 Sep 24 07:38:30 Tower kernel: mdcmd (29): import 28 Sep 24 07:38:31 Tower kernel: mdcmd (30): import 29 sdk 64 3907018532 0 HGST_HDN726040ALE614_K7H4DS5R - ORIGINAL PARITY 5TH TIME Sep 24 07:38:31 Tower kernel: md: import disk29: (sdk) HGST_HDN726040ALE614_K7H4DS5R size: 3907018532 Sep 24 07:38:31 Tower emhttpd: import 30 cache device: (sdb) Samsung_SSD_870_EVO_1TB_S75BNS0W531612Z Sep 24 07:38:31 Tower emhttpd: import 31 cache device: (sdd) Samsung_SSD_870_EVO_1TB_S75BNS0W540967Z Sep 24 07:38:31 Tower emhttpd: import 32 cache device: (sdf) Samsung_SSD_870_EVO_1TB_S75BNS0W531603P Sep 24 07:38:31 Tower emhttpd: import flash device: sda Sep 24 07:38:31 Tower root: Submitting SysDrivers Build Sep 24 07:38:31 Tower SysDrivers: SysDrivers Build Starting Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdm Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdj Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdk Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdh Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdg Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdd Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sde Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdb Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdf Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdc Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdn Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdo Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdl Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdi Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sdp Sep 24 07:38:31 Tower emhttpd: read SMART /dev/sda Sep 24 07:38:49 Tower SysDrivers: SysDrivers Build Complete Sep 24 07:39:02 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update

I didn't have any problems swapping parity with a larger disk and rebuilding the data disk using the original parity. Reviewing your logs, it looks like the process started again (probably because you initiated again since it was only option). I'm not sure what to make of that. It looks like the configuration just didn't agree with the copy that previously occurred. Maybe someone else would be able to interpret better. Sep 23 18:49:53 Tower emhttpd: copy: disk5 to disk0 running ... Sep 24 07:38:13 Tower emhttpd: copy: disk5 to disk0 completed Then it started again.. Sep 24 07:59:42 Tower emhttpd: copy: disk5 to disk0 running General observations: Step 5-8. If the drives are already installed as unassigned, steps 5-8 are not necessary. Step 9. The array was already stopped from step 4 or at power on from step 8. Step 9 seems wrong.

I've never used this procedure before, but I started a parity drive replacement for you as part of step 14. I'll let you know what I find out.

Yes, it does. That's the great debate. In the hypothetical version of Unraid, checking the "surplus" would be optional for recurring syncs, but an initial sync would be required. Parity isn't calculated when adding a data disk. Replacing a parity disk will kick off a parity sync and calculate parity against all data disks. Once it reaches the end of the data disks, it will continue to zero the remaining sectors of the parity disk. Data disks must be cleared by native Unraid clear or UD pre-clear plugin (optional). This guarantees parity remains even and is the reason a parity sync isn't needed upon adding a data disk.

Is your question that you want to reinstall the Unraid OS and use the same license key?

For anyone looking for the checksum binary compare script by Joe L. and discovered the link in this post is dead, I found it attached to this thread.

I found it attached to this thread.

In my search for his script, I came across your post. I found it attached to this thread.

This is true, but if that bad sector happens to land on the "surplus" portion of the parity disk, does that truly invalidate parity? Of course adding a new disk that absorbs that bad area is a problem and performing full parity check on regular cycles reduces your chance of a surprise error. In theory, is it reasonable to think checking the remainder of the parity drive should be optional?

I was referring to his binary checksum duplicate files script. (Didn't mean to take over this guy's thread, but maybe the info will help him.)

One of them was new. The other was disk2.

It looked like disk6 and disk7 were also formatted.

Thanks. Do you happen to know if @Joe L.'s script is still available somewhere? The link in that thread is broken and I'm interested his too.