On Sun, Oct 22 2017, sfunk1x wrote:

On 10/19/2017 06:50 PM, NeilBrown wrote:

quoted

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.

quoted

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