On 11/21/2017 12:21 PM, Wol's lists wrote:
#!/bin/bash dd if=/dev/zero of=$1 bs=512 count=2018 dd if=/dev/zero of=$1 bs=512 seek=$(( $(blockdev --getsz $1) - 1024 )) count=1024 exit
Does the second line wipe the END of the disk?
Yes, our hardware RAID (LSI) appends a fairly large number of sectors at the end of the disk for metadata. The size of this area seems to change depending on the card model number, the 1024 blocks seems to cover all the bases. BTW, when the RAID controller reports the size of the disk, it doesn't include this metadata area. So a disk connected to a RAID controller appears to be smaller than a directly connected one. I think mdadm does the same thing.
Note that your backup GPT is located at the end of the disk, and a v0.9 or v1.0 raid superblock is also located at the end of the partition/disk.
Not knowing where everything is stored, that's why my preference is simply to wipe the entire disk. Snag, of course, is that it takes a LLOOOONNGGG time on today's huge disks.
Yes, we're routinely using Seagate 10-TB disks now. They're interesting, the top of the disk is welded into place to try to keep the helium inside. There's a low-helium alarm too. They're warrantied for 5-years, so we'll see.
BTW, I've also seen software raid (mdadm) get confused by disks out of a hardware raid controller.
What's the betting the firmware in said contoller is a cut-down linux/mdadm combo? :-)
There seems to be a common signature element between the LSI controllers and mdadm. Which came first? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org