On Sat, 2010-02-20 at 22:30 +0100, Asdo wrote: > Robert Hancock wrote: > >> [CUT] > >> In the past I was doing: > >> > >> blockdev --rereadpt /dev/sdX > >> > >> and it usually worked on other controllers to reread the size visible > >> from "blockdev --getsize" or "blockdev --getsize64". One time I think it > >> even worked on exactly *that* controller... but it's not working now, > >> it's strange. > >> > >> Is there a technique, or I am out of luck? > >> The machine should not be rebooted > >> I would even enter the size manually if possible: I know how many LBA > >> blocks are in that disk. > > > > What dmesg output do you get when you do this? > > with "this" I suppose you mean the blockdev --rereadpt? > > This is the dmesg I get upon blockdev --rereadpt: > > [508100.472337] sd 3:0:1:0: [sdr] 1465149168 512-byte hardware sectors > (750156 MB) > [508100.472376] sd 3:0:1:0: [sdr] Write Protect is off > [508100.472381] sd 3:0:1:0: [sdr] Mode Sense: 00 3a 00 00 > [508100.472412] sd 3:0:1:0: [sdr] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [508100.472418] sdr: unknown partition table > > > It rereads the wrong size, i.e. the one of the old disk :-( > I am sure sdr is the correct disk, I even identified it by doing dd > if=/dev/sdr of=/dev/null and then looking at the activity led to confirm > it's the right drive. It should have read a size of 1TB. What's happening is that libata is returning the old cached size to READ_CAPACITY. This would likely indicate some type of libata hotplug failure ... the dmesg across the unplug/plug would be useful for diagnosing this. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
