December 12, 20232 yr I'm having the exact same issue as here - I've been moving data from my xfs disks around, to clear a disk, swapping to zfs All has been going well - done disk 5, 4 and 3 Just moved everything from disk 2 to disk 3, stopped the array to change disk 2 to ZFS and it's warning me that disk 3 is the wrong disk The logs for disk 3 show that the size has changed Dec 6 17:12:18 Jarvis kernel: ata38: SATA max UDMA/133 abar m2048@0xfbc00000 port 0xfbc00180 irq 70 Dec 6 17:12:18 Jarvis kernel: ata38: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Dec 6 17:12:18 Jarvis kernel: ata38.00: ATA-10: WDC WD60EDAZ-11U78B0, 80.00A80, max UDMA/133 Dec 6 17:12:18 Jarvis kernel: ata38.00: 11721045168 sectors, multi 16: LBA48 NCQ (depth 32), AA Dec 6 17:12:18 Jarvis kernel: ata38.00: Features: NCQ-prio Dec 6 17:12:18 Jarvis kernel: ata38.00: configured for UDMA/133 Dec 6 17:12:18 Jarvis kernel: sd 39:0:0:0: [sdh] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB) Dec 6 17:12:18 Jarvis kernel: sd 39:0:0:0: [sdh] 4096-byte physical blocks Dec 6 17:12:18 Jarvis kernel: sd 39:0:0:0: [sdh] Write Protect is off Dec 6 17:12:18 Jarvis kernel: sd 39:0:0:0: [sdh] Mode Sense: 00 3a 00 00 Dec 6 17:12:18 Jarvis kernel: sd 39:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 6 17:12:18 Jarvis kernel: sd 39:0:0:0: [sdh] Preferred minimum I/O size 4096 bytes Dec 6 17:12:18 Jarvis kernel: sdh: sdh1 Dec 6 17:12:18 Jarvis kernel: sd 39:0:0:0: [sdh] Attached SCSI disk Dec 6 17:13:20 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 6 17:13:20 Jarvis kernel: mdcmd (4): import 3 sdh 2048 5860521540 0 WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ Dec 6 17:13:20 Jarvis kernel: md: import disk3: (sdh) WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ size: 5860521540 Dec 6 17:13:20 Jarvis emhttpd: read SMART /dev/sdh Dec 8 03:20:42 Jarvis emhttpd: spinning down /dev/sdh Dec 8 04:01:47 Jarvis emhttpd: read SMART /dev/sdh Dec 8 22:59:21 Jarvis emhttpd: read SMART /dev/sdh Dec 8 22:59:42 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 8 22:59:42 Jarvis kernel: mdcmd (4): import 3 sdh 2048 5860521540 0 WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ Dec 8 22:59:42 Jarvis kernel: md: import disk3: (sdh) WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ size: 5860521540 Dec 8 22:59:42 Jarvis emhttpd: read SMART /dev/sdh Dec 11 06:44:23 Jarvis emhttpd: spinning down /dev/sdh Dec 11 08:08:45 Jarvis emhttpd: read SMART /dev/sdh Dec 11 11:01:58 Jarvis emhttpd: read SMART /dev/sdh Dec 11 11:02:16 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 11 11:02:16 Jarvis kernel: mdcmd (4): import 3 sdh 2048 5860521540 0 WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ Dec 11 11:02:16 Jarvis kernel: md: import disk3: (sdh) WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ size: 5860521540 Dec 11 11:02:17 Jarvis emhttpd: read SMART /dev/sdh Dec 11 11:04:18 Jarvis emhttpd: shcmd (352990): /sbin/wipefs -af /dev/sdh Dec 11 11:04:18 Jarvis root: /dev/sdh: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54 Dec 11 11:04:18 Jarvis root: /dev/sdh: 8 bytes were erased at offset 0x57541e95e00 (gpt): 45 46 49 20 50 41 52 54 Dec 11 11:04:18 Jarvis root: /dev/sdh: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa Dec 11 11:04:18 Jarvis emhttpd: writing GPT on disk (sdh), with partition 1 byte offset 32KiB, erased: 0 Dec 11 11:04:18 Jarvis emhttpd: shcmd (352991): sgdisk -Z /dev/sdh Dec 11 11:04:19 Jarvis emhttpd: shcmd (352992): sgdisk -o -a 8 -n 1:32K:0 /dev/sdh Dec 11 11:04:20 Jarvis kernel: sdh: sdh1 Dec 12 20:51:22 Jarvis emhttpd: read SMART /dev/sdh Dec 12 20:51:41 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 12 20:51:41 Jarvis kernel: mdcmd (4): import 3 sdh 64 5860522532 0 WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ Dec 12 20:51:41 Jarvis kernel: md: import disk3: (sdh) WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ size: 5860522532 Dec 12 20:51:42 Jarvis emhttpd: read SMART /dev/sdh Dec 12 20:52:18 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 12 20:52:18 Jarvis emhttpd: read SMART /dev/sdh Dec 12 20:52:22 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 12 20:52:22 Jarvis kernel: mdcmd (4): import 3 sdh 64 5860522532 0 WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ Dec 12 20:52:22 Jarvis kernel: md: import disk3: (sdh) WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ size: 5860522532 Dec 12 20:52:22 Jarvis emhttpd: read SMART /dev/sdh Dec 12 20:53:03 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 12 20:53:03 Jarvis emhttpd: read SMART /dev/sdh Dec 12 20:53:08 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 12 20:53:08 Jarvis kernel: mdcmd (4): import 3 sdh 64 5860522532 0 WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ Dec 12 20:53:08 Jarvis kernel: md: import disk3: (sdh) WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ size: 5860522532 Dec 12 20:53:08 Jarvis emhttpd: read SMART /dev/sdh Dec 12 20:55:07 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 12 20:55:07 Jarvis emhttpd: read SMART /dev/sdh Dec 12 20:57:54 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 12 20:57:54 Jarvis kernel: mdcmd (4): import 3 sdh 64 5860522532 0 WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ Dec 12 20:57:54 Jarvis kernel: md: import disk3: (sdh) WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ size: 5860522532 Dec 12 20:57:54 Jarvis emhttpd: read SMART /dev/sdh Dec 12 20:58:19 Jarvis emhttpd: WDC_WD60EDAZ-11U78B0_WD-WX22D70KRVPJ (sdh) 512 11721045168 Dec 12 20:58:20 Jarvis emhttpd: read SMART /dev/sdh Yesterday it was reporting as 5860521540 and then after the zfs format it's reporting as 5860522532 but the array config is now saying this is the wrong disk! I am extremely nervous now because there's been a lot of files moved around over the last few days during my zfs conversion, and changing of filesystems. The parity should be fine, but I'd really rather not let it rebuild the disk from parity over what's on there in case I lose everything! Is there any way at all that I can just fix the array config, and tell it that it really is the correct disk and then after it's mounted I can do a parity check? Any help very much appreciated at this point jarvis-diagnostics-20231212-2114.zip Edited December 12, 20232 yr by PhilBarker
December 12, 20232 yr Author As per the instructions on the other thread I've tried starting the array with the disk removed. All files seem to be emulated ok, I can access them without issues. Attached new diagnostics with the disk now emulated. Does this mean I'm best just to add the disk back in and let it rebuild it from parity? jarvis-diagnostics-20231212-2129.zip
December 13, 20232 yr Community Expert Solution 11 hours ago, PhilBarker said: Yesterday it was reporting as 5860521540 and then after the zfs format it's reporting as 5860522532 but the array config is now saying this is the wrong disk! It suggests that previously it was partitioned with the non default 64 starting sector, i.e., disk had been partitioned before being assigned to Unraid, likely on sector 2048 since Unraid will accept it. 11 hours ago, PhilBarker said: Does this mean I'm best just to add the disk back in and let it rebuild it from parity? If the emulated disk mounts and contents look correct you can rebuild.
December 13, 20232 yr Author 19 minutes ago, JorgeB said: It suggests that previously it was partitioned with the non default 64 starting sector, i.e., disk had been partitioned before being assigned to Unraid, likely on sector 2048 since Unraid will accept it. If the emulated disk mounts and contents look correct you can rebuild. Thanks, I've kicked off a rebuild - fingers crossed! Your explanation probably makes sense, I had a native ubuntu server before moving to unraid, the disk might have been moved over from there and I forgot to zero it out first.
December 19, 20232 yr Author Just to close this off in case anyone else has the same issue in the future This 100% was my problem - the disk must have been formatted in my old server and transferred across without being wiped. It was the only disk with a 1MiB GPT, all the others are 4KiB. So when I formatted from exfs to zfs the size of the disk reported changed. The parity restore worked flawlessly and no lost data. The only other weird issue I had was the file integrity plugin started saying the hash's had changed for most of the files on disk3, again likely because of the GPT. I simply checked the files were ok, then removed the hash's and recalculated. All 4 of my other disks reformatted to ZFS without issues 😄
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.