dboonthego

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.

@itimpi - Is unRAIDFindDuplicate_v1.5.zip the most recent version of your script? I was reading this thread the other day and this post reminded me I need to go back and download it.

You might have better response if you post in the support thread. https://forums.unraid.net/topic/111725-support-diamondprecisioncomputing-all-images-and-files

I'll admit I'm not the best at interpretation of the logs. If you formatted (which it looks like you did) hopefully you have a backup. I wouldn't do anything further without advice from someone more experienced. This does not look good. Sep 17 22:00:56 Tower emhttpd: shcmd (95378): /sbin/wipefs -a /dev/md2

A good backup is always a good plan. Swap the hardware and fire it up. I think you'll be fine.

Yes it does. And to your original question, I have wondered the same. It seems reasonable to think a parity check only needs to go as far as the largest data drive. There must be a sound reason. Can a rogue parity bit mysteriously flip from 0 to 1? 🤷‍♂️

You can't. The contents are emulated from parity. You need to resolve the issue to bring it back. More commonly its a connection problem. You can try re-seating power and data cables and/or re-arrange them. If the problem follows to new disk, replace the cable. Post a diagnostics zip to your next post.

Having a backup is never a bad plan.

Other than configuring SMTP and allowing time to build an inbox of alerts your system generates, I don't think there's a way. It sounds like a list isn't available or published. The balloon or smtp notification was all I found; nothing in syslog. In my case, I was performing disk2disk copy so I knew why it was triggered.

Just for kicks, what happens if you try your rsync test again without the archive (-a) flag?