Bug 113693 - hdparm ide hotswap leaves wrong information in kernel
hdparm ide hotswap leaves wrong information in kernel
Product: Fedora
Classification: Fedora
Component: hdparm (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Karsten Hopp
Depends On:
  Show dependency treegraph
Reported: 2004-01-16 11:09 EST by Keith Lofstrom
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-06 00:58:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Keith Lofstrom 2004-01-16 11:09:22 EST
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

"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):

How reproducible:

Steps to Reproduce:
1.  Put two different sized, similarly partitioned drives in hot swap
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.
Comment 1 Keith Lofstrom 2004-03-06 00:58:39 EST
Duh.  Color me stupid.  After looking at the code, and an enlightened
RTFM, I realized I should have been reconnecting the drive with

hdparm -zb 1 /dev/hdg   instead of   hdparm -b 1 /dev/hdg . 

The z option runs the  ioctl(fd, BLKRRPART )  after the bus is 

So, let's mark this bug "imaginary" and I will slink off into a corner.

Note You need to log in before you can comment on or make changes to this bug.