From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Description of problem:
This is probably a problem in the kernel's ide driver code, but it
manifests in hdparm.  See http://www.keithl.com/idebug  for more
details.  

"hdparm -b0 <drive>" and "hdparm -b1 <drive>" functionality was added
by Alan Cox, and is very useful for swapping secondary IDE drives on
running systems.  However, when the swapped new drive is a different
geometry, the hdparm command is not updating whatever data structures
keep track of it.  Thus, if I try to access the outer regions of a 
larger drive, I get errors, and fdisk shows the wrong info.

A workaround involves running sfdisk then control-C ing out of it.
However, that is dangerous, annoying, and not automatable.  

This is repeatable, and is easy to do with hotswap drive cages.  For 
more suggestions on choosing and purchasing those drive cages (about 
$30 for the hardware), see:  http://www.keithl.com/linuxbackup.html 
I would be happy to donate a set of cages to the person assigned to
work on this problem.

Version-Release number of selected component (if applicable):
hdparm-5.4-3

How reproducible:
Always

Steps to Reproduce:
1.  Put two different sized, similarly partitioned drives in hot swap
cages
2.  Boot with smaller drive as a secondary drive, say /dev/hdg
3.  hdparm -b 0 /dev/hdg
4.  power down swap cage, excange for larger drive, power up cage
5.  hdparm -b 1 /dev/hdg
6.  sfdisk -g /dev/hdg

    

Actual Results:  sfdisk will report the wrong disk size and geometry.
 This can cause
problems later, when writing data to the drive.  I have lost the data
on one drive to such problems.

Expected Results:  sfdisk should report the correct size and geometry
for the new drive,
and read and write operations should not have problems or corrupt
data on the disk.

Additional info:

Again, see the description at www.keithl.com/idebug for more info.