Skip to contentSkip to conversation

How to reread disk size?

DISCUSSION Asdo 3 participants 8 messages Feb 20, 2010 – Feb 23, 2010 2 messages not in the archive libata

lore
Share & tools
lore

Asdo

author
#0 lore raw

Hi all,
I have a system with hot swappable bays but one of the involved controllers apparently does not support hot swap:
(I have unfortunately an old kernel: 2.6.24)

00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller (rev 09) (prog-if 8f [Master SecP SecO PriP PriO])

       Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 19
       I/O ports at 18c8 [size=8]
       I/O ports at 18ac [size=4]
       I/O ports at 18c0 [size=8]
       I/O ports at 18a8 [size=4]
       I/O ports at 18b0 [size=16]
       Memory at da804400 (32-bit, non-prefetchable) [size=1K]
       Capabilities: [70] Power Management version 2

I have swapped the disk with a larger one (750GB -> 1TB) but it blockdev --getsize64 still sees the old size. It has not realized I have swapped disk.

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.

Thank you

#1 lore raw
Quoted 30 lines · Asdo

Hi all,
I have a system with hot swappable bays but one of the involved controllers apparently does not support hot swap:
(I have unfortunately an old kernel: 2.6.24)

00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller (rev 09) (prog-if 8f [Master SecP SecO PriP PriO])
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 19 I/O ports at 18c8 [size=8]
I/O ports at 18ac [size=4]
I/O ports at 18c0 [size=8]
I/O ports at 18a8 [size=4]
I/O ports at 18b0 [size=16]
Memory at da804400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [70] Power Management version 2

I have swapped the disk with a larger one (750GB -> 1TB) but it blockdev --getsize64 still sees the old size. It has not realized I have swapped disk.

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.

Quoted 4 lines

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?

author
#2 lore raw
Quoted 10 lines · Robert Hancock
Quoted 10 lines

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

Quoted 6 lines
Quoted 4 lines

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.

Thanks for your help

author
#3 lore raw
Quoted 3 lines · Asdo

[...]
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.

I can also add that smartctl -a /dev/sdr reads the CORRECT size... (but it does not update the size in the linux's block device obviously)

:-( ...

#4 lore raw
In reply to Asdo
Quoted 31 lines · Asdo
Quoted 10 lines · Robert Hancock
Quoted 10 lines

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

Quoted 6 lines
Quoted 4 lines

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
Quoted 4 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#7 lore raw
Quoted 11 lines · Robert Hancock

ata_piix doesn't have a way to get automatically notified that the disk has been hotplugged since the chipset doesn't support it in this mode. (The ideal solution would be to switch the controller into AHCI mode, but I don't know if that's possible on that chipset and BIOS.)

I think there are some ways to get the code to recheck the disk however.. you can try echoing something into the "rescan" sysfs file under /sys that matches your device (do a "find /sys/ -name scsi_level" to see what directories they're in, the rescan file is in the same directory).

Thanks for the hint
It doesn't work unfortunately.
Echoing something into rescan makes it output (in dmesg) basically the same message that comes out with blockdev --rereadpt /dev/sdr. The size is still detected wrong. Catting "model" also turns out that the old brand of disk still being detected. smartctl -a does show the new disk :-) I tried to write "1" in evt_media_change but it's permission denied :-)

Thank you

#8 lore raw
Quoted 13 lines · Asdo
Quoted 11 lines · Robert Hancock

ata_piix doesn't have a way to get automatically notified that the disk has been hotplugged since the chipset doesn't support it in this mode. (The ideal solution would be to switch the controller into AHCI mode, but I don't know if that's possible on that chipset and BIOS.)

I think there are some ways to get the code to recheck the disk however.. you can try echoing something into the "rescan" sysfs file under /sys that matches your device (do a "find /sys/ -name scsi_level" to see what directories they're in, the rescan file is in the same directory).

Quoted 7 lines

Thanks for the hint
It doesn't work unfortunately.
Echoing something into rescan makes it output (in dmesg) basically the same message that comes out with blockdev --rereadpt /dev/sdr. The size is still detected wrong. Catting "model" also turns out that the old brand of disk still being detected. smartctl -a does show the new disk :-) I tried to write "1" in evt_media_change but it's permission denied :-)

Right. libata caches the value from the moment it scans the device. You might be able to alter it by having the device destroyed and recreated ... that would be echoing 1 to the delete under the scsi device sysfs node and then echoing '- - -' to the host rescan parameter. If that doesn't work, libata will need to be fixed somehow because that would mean it isn't slaving it's device lifetimes to the SCSI model.

James

author
#9 lore raw
Quoted 22 lines · James Bottomley
Quoted 14 lines · Asdo
Quoted 5 lines · Robert Hancock

ata_piix doesn't have a way to get automatically notified that the disk has been hotplugged since the chipset doesn't support it in this mode. (The ideal solution would be to switch the controller into AHCI mode, but I don't know if that's possible on that chipset and BIOS.)

Quoted 7 lines

I think there are some ways to get the code to recheck the disk however.. you can try echoing something into the "rescan" sysfs file under /sys that matches your device (do a "find /sys/ -name scsi_level" to see what directories they're in, the rescan file is in the same directory).

Quoted 5 lines

Thanks for the hint
It doesn't work unfortunately.
Echoing something into rescan makes it output (in dmesg) basically the same message that comes out with blockdev --rereadpt /dev/sdr. The size is still detected wrong. Catting "model" also turns out that the old brand of disk still being detected. smartctl -a does show the new disk :-) I tried to write "1" in evt_media_change but it's permission denied :-)

Quoted 7 lines

Right. libata caches the value from the moment it scans the device. You might be able to alter it by having the device destroyed and recreated ... that would be echoing 1 to the delete under the scsi device sysfs node and then echoing '- - -' to the host rescan parameter. If that doesn't work, libata will need to be fixed somehow because that would mean it isn't slaving it's device lifetimes to the SCSI model.

Great, it works! Thank you

root@mynode:/sys# echo 1 > /sys/devices/pci0000:00/0000:00:1f.2/host3/target3:0:1/3:0:1:0/delete

and then

echo "- - -" > /sys/class/scsi_host/host3/scan

recreated the device with 1TB size!

Acually then I tried to swap disks again and just give the
echo "- - -" > /sys/class/scsi_host/host3/scan
and it worked already. So deleting the device was not needed.
However the "rescan" in the same directory of scsi_level you suggested in previous post did not work. This "scan" in scsi_host is more powerful :-D

Thank you