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 -- 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
