On Tue, Sep 13, 2011 at 6:57 PM, Andriano <chief000@xxxxxxxxx> wrote: > On Tue, Sep 13, 2011 at 6:44 PM, Roman Mamedov <rm@xxxxxxxxxx> wrote: >> On Tue, 13 Sep 2011 17:51:56 +1000 >> Andriano <chief000@xxxxxxxxx> wrote: >> >>> Apparently you're right >>> blockdev --getsz /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg >>> /dev/sdh /dev/sdi /dev/sdj /dev/sdk >>> 3907027055 >>> 3907027055 >>> 3907029168 >>> 3907029168 >>> 3907029168 >>> 3907029168 >>> 3907027055 >>> 3907029168 >>> 3907029168 >>> 3907029168 >>> >>> sdb, sdc and sdh - are smaller and they are problem disks >>> >>> So what would be a solution to fix this issue? >> >> You mentioned you use Gigabyte EP35C-DS3 motherboard. Gigabyte BIOSes are known to cut off about 1 MByte or so from the end of HDDs (on the onboard controller, and maybe just the one on Port 0), setting an HPA area and storing a copy of the BIOS there. That's known as "(Virtual) Dual/Triple/Quad BIOS". Google for "gigabyte bios hpa" and you'll find a lot of reports about this problem. You can check if you can disable that "feature" in BIOS setup, but older boards did not have such option. >> >> To restore the native capacity of the drives you can use "hdparm -N" (see its man page), while disks are on the non-onboard controller. >> >> In the future, create your RAID from partitions, and leave 8-10 MB of space in the end of each disk for cases like these. >> >> -- >> With respect, >> Roman >> > > Roman, > > Looks like you have pointed to the source of the problem. The option > to backup BIOS has been enabled. > Is "hdparm -N" going to affect superblock or data integrity of these > disks? Or has that backup already done the damage? > > thanks > > Andrew > Connected one of the offenders to HBA port, and hdparm outputs this: #hdparm -N /dev/sdh /dev/sdh: max sectors = 3907027055/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) -- 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