On Thu, Mar 08, 2018 at 02:32:05PM -0500, John Maguire wrote: > my array came back in "auto-read-only" mode That's normal. Goes away when you actually write something to it. > with two devices missing. Less normal. > I added them back into the array, and rebooted again, > and experienced the same results. If you can reliably reproduce it, hexdump the first few megs and then diff. That way you know in detail which bytes are being changed and it might point to the culprit. > Another user reported that by switching from block devices (e.g. > /dev/sda, /dev/sdb) to partition (e.g. /dev/sda1, /dev/sdb1), their > issue went away. You should be doing that anyway. Never use bare block devices. Always have a partition table first. Too much software relies on it, and quietly "helps" you by creating one if it is missing. > Avail Dev Size : 15627791024 (7451.91 GiB 8001.43 GB) > Array Size : 15627790336 (14903.82 GiB 16002.86 GB) > Used Dev Size : 15627790336 (7451.91 GiB 8001.43 GB) This looks weird because mdadm uses confusing units. > /dev/sda: > MBR Magic : aa55 > Partition[0] : 4294967295 sectors at 1 (type ee) A wild partition table appeared. Is it empty or are specific partitions created too? (parted -l) GPT partition tables also have a metadata backup at the end of the drive. Something might be "helpfully" using that backup to restore it for you. So try zeroing both start and end of the drive before re-adding it. But even if that works, it's not a good solution. If the array was using the full drive and reached to the very end of the drive and had a GPT partition table on top of the array, it's possible that the GPT header of the array might be interpreted as GPT header of the raw drive instead. But it shouldn't be the case here since your array leaves some unused sectors at the end of the drives. Regards Andreas Klauer -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
