aim60 Posted April 9 Share Posted April 9 Running 6.12.8 My array has 2 parity disks. I was in the process of rebuilding parity1 onto a larger disk. About half way through, I paused the rebuild to do some significant array access. Upon resuming the rebuild, the following showed in the syslog. Apr 8 22:04:41 Tower7 emhttpd: writing GPT on disk (sdj), with partition 1 byte offset 32KiB, erased: 0 Apr 8 22:04:41 Tower7 emhttpd: shcmd (161402): sgdisk -Z /dev/sdj Apr 8 22:04:42 Tower7 root: GPT data structures destroyed! You may now partition the disk using fdisk or Apr 8 22:04:42 Tower7 root: other utilities. Apr 8 22:04:42 Tower7 emhttpd: shcmd (161403): sgdisk -o -a 8 -n 1:32K:0 /dev/sdj Apr 8 22:04:42 Tower7 kernel: sdj: sdj1 Apr 8 22:04:43 Tower7 kernel: sdj: sdj1 Apr 8 22:04:43 Tower7 root: Creating new GPT entries in memory. Apr 8 22:04:43 Tower7 root: The operation has completed successfully. Apr 8 22:04:43 Tower7 emhttpd: re-reading (sdj) partition table Apr 8 22:04:43 Tower7 emhttpd: shcmd (161404): udevadm settle Apr 8 22:04:43 Tower7 kernel: sdj: sdj1 Apr 8 22:04:52 Tower7 kernel: mdcmd (38): check resume Apr 8 22:04:52 Tower7 kernel: md: recovery thread: recon P ... The rebuild completed successfully. I now need to determine if the contents of parity1 are valid. Since a non-correcting parity check would take almost a full day, I’m looking for an opinion as to the condition of parity1. If it is thought it is valid, I will do the non-correcting parity check. If not, I assume the way to proceed is to stop the array, wipe parity1 and redo the rebuild without pausing. tower7-diagnostics-20240409-1328.zip Quote Link to comment
Solution JorgeB Posted April 9 Solution Share Posted April 9 I think it was because of this: Apr 8 08:53:34 Tower7 root: Creating new GPT entries in memory. Apr 8 08:53:34 Tower7 root: Warning: The kernel is still using the old partition table. Apr 8 08:53:34 Tower7 root: The new table will be used at the next reboot or after you Apr 8 08:53:34 Tower7 root: run partprobe(8) or kpartx(8) Apr 8 08:53:34 Tower7 root: The operation has completed successfully. Apr 8 08:53:34 Tower7 emhttpd: re-reading (sdj) partition table Apr 8 08:53:34 Tower7 emhttpd: error: mkmbr, 2196: Device or resource busy (16): ioctl BLKRRPART: /dev/sdj When the disk was initially partitioned it was busy, so possibly because of that it tried again after the resume, I'm just guessing since it's the first time I see this, the second partitioning attempt, not the disk busy issue, that has been happening for some time, hopefully it won't anymore with v6.13, since there were some changes done to try and prevent that. I would be extremely surprised if parity wasn't valid, just re-partitioning the disk should not cause any changes to the parity info, but you can start a check and let it run for a few minutes, if the no errors are found immediately it should all be fine. 1 Quote Link to comment
aim60 Posted April 9 Author Share Posted April 9 The check has been running for a while now, without errors. Thanks 1 Quote Link to comment
Recommended Posts
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.