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

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.

The check has been running for a while now, without errors. Thanks