On 2021-03-26 12:28, Andy Smith wrote:
Actually, the link shows that they eventually did exactly what I did - throw up their hands and go back to using disks with a single partition.Hello, On Mon, Mar 22, 2021 at 06:20:56PM -0400, Gary Dale wrote:I've found many other people complaining about similar issues when using whole disks to create mdadm RAID arrays. Some of these complaints go back many years, so this isn't new.Any time I've seen this problem pursued (as opposed to throwing up hands and just using partitions) it was found to be the motherboard (well, the UEFI bit) deciding that a storage device with no GPT or MBR needs an empty GPT adding to it. This corrupts md arrays on whole devices. Example: http://forum.asrock.com/forum_posts.asp?TID=10174&title=asrock-motherboard-destroys-linux-software-raid Is it possible that this is happening to you? If not, once again I urge you to go on over to linux-raid list and describe what's happening. Cheers, Andy
If there are a significant number of BIOSs that overwrite mdadm raid information when using whole disks then that is a definition of unreliable. Imagine swapping out a motherboard and finding your RAID array has vanished.
The link to the ASRock page suggests that it is a common "feature" in their recent AMD motherboards, I don't know if that also appears in Gigabyte AMD boards. Nor can I think of a reason why it would be specific to AMD boards.
It doesn't appear to be related to the drives unless Seagate, WD and HGST all suffer from the problem.
However, I'm not convinced that the problem is the BIOS writing a partition table. In your link the last post talks about zapping the partition table to stop the behaviour. This suggests the BIOS/UEFI was restoring the backup partition table. However I'd already zapped the partition table on my disks so that wouldn't be my case.