On Sun, Oct 22 2017, sfunk1x wrote: > On 10/19/2017 06:50 PM, NeilBrown wrote: > >> Thanks. sdf looks like it might have a gpt partition >> table on it. The "od -x" supports that. What does "fdisk -l /dev/sdf" >> show? What about >> mdadm --examine /dev/sdf* >> ?? > > fdisk -l /dev/sdf: > > Disk /dev/sdf: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 4096 bytes > I/O size (minimum/optimal): 4096 bytes / 4096 bytes > Disk label type: gpt > Disk identifier: 5B742241-93F1-4FE1-9CA6-525F759E38B1 > > > # Start End Size Type Name > 1 2048 5860533134 2.7T Linux RAID > This seems to suggest that you did prepare to use sdf1 (rather than sdf) in the array, but it isn't conclusive proof. > > mdadm --examine /dev/sdf* > > /dev/sdf: > MBR Magic : aa55 > Partition[0] : 4294967295 sectors at 1 (type ee) > mdadm: No md superblock detected on /dev/sdf1. No metadata on sdf1 - sad. That is what I was hoping for. > > > >> >> I should have suggested " | head" at the end of the 'grep' >> command. Maybe make it >> od -x /dev/sdf | grep '4efc a92b' | head >> That will look for md metadata. > > It's actually still running, but this is the output so far: > > [root@hemlock ~]# od -x /dev/sdf | grep '4efc a92b' | head > 142401762260 7984 d854 643a 3c8f dd3a a8de 4efc a92b > 156441541400 48f9 9523 3539 de0a d1f4 4efc a92b 60a8 > 214717071120 ac68 a62e 441c c0f8 85c1 cab7 4efc a92b > 367526264660 dc8f 4f52 4efc a92b fd99 4744 1d6e c59f > 515240166540 4f6a c1eb 5309 4efc a92b d0ad b3ee 11a0 > 575452271660 b669 7eeb 4efc a92b ebf5 c069 c78d 82d3 > 1026007653000 913f 4efc a92b 0b3d 5e94 9f7a 80a5 6e0c > 1104130763160 7267 f0e5 e9a4 a9e0 0b85 5b3b 4efc a92b > 1107535224640 cde4 efa8 557c 01a1 1abb b885 4efc a92b > 1167200747300 49dd f3e2 4efc a92b a6e7 f1af 7af1 e6c6 No md metadata to be found at all. We would need to see a line with an address ending "000" and data starting 4efc a92b 0001 0000 .... Nothing like that here. Maybe this isn't really the drive you think it is? Could someone or something have swapped drives? Maybe you or someone zeroed the metadata (mdadm --zero-super /dev/sdf1). There is no way that md or mdadm could have mis-behaved, even when affected by selinux, to produce this result. Something else must have happened. Maybe something you don't know about, or something you don't think it relevant. But there must be something. Sorry I cannot be more helpful. NeilBrown
Attachment:
signature.asc
Description: PGP signature
