https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #28 from Peter Wemm <pe...@freebsd.org> --- There's no size decreases. The sizes match what is in the initial probe messages. What's happening is that the disk is mis-partitioned like this: Disk size: 143374650 sectors sector 0: PMBR sector 1-39: GPT 40-143374615: partition space inside gpt 143374610-143374649 backup GPT Note the overlap, da0-da5 are all like this. dmesg says: da1 at mpt0 bus 0 scbus0 target 1 lun 0 da1: <FUJITSU MAS3735NC 5B08> Fixed Direct Access SCSI-3 device da1: Serial Number A107P49025H2 da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da1: Command Queueing enabled da1: 70007MB (143374650 512 byte sectors) There is no size change. The problem is that instead of copying the media size, you're introducing a new resize event at open time that wasn't there before - even when there's no resize. g_part is now calling its resize code paths and trying to make sense. GEOM_PART: partition 3 has end offset beyond last LBA: 143374615 > 143374610 GEOM_PART: integrity check failed (da1, GPT) This matches the bad partitioning and the GPT should have been rejected the very first time around. The problem is that it is only being detected perhaps 1 in 10 times. Aside from the panic, the second problem is the inconsistency. It should be attempting to repair all 6 drives, but isn't. Sometimes it doesn't detect any of the bad disks and boots successfully. Is the event getting lost? I think you're racing with initialization / tasting somehow and I suspect that's a bigger problem. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-geom@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
