Hard disk LBA sector count is not always the same
PATCH RESEND 1/1 Hard disk LBA sector count is not always the same
Hi all :)
I'm resending this because although it doesn't seem to imply a
hard disk failure, I have to repartition this disk and I must do it using a 2.6 kernel (long story), and I'm afraid that afterwards I cannot access the last sectors using 2.4 (since sometimes the disk is detected as being 2103 sectors smaller. I would appreciate any help, or if someone could point me to a source of information or a more appropriate mailing list.
I'm having a problem with my primary hard disk: it inconsistently
reports the number of addressable LBA sectors. At times it reports 156301488 (let's call it '301' from now on) which is the correct one (I think) and other times it reports 156299375 (I'll call this one 299 from now on), a difference of 2103 sectors. But this is not arbitrary, I have reproduced the problem. I've done it using a self-compiled 2.4.29 kernel and a 2.6.10-1-k7 kernel from Debian unstable. These are the steps:
STEP 1: From a fully powered off machine, I boot into my 2.4.29
kernel. The kernel log shows the 299 number, as well as does both hdparm -i and hdparm -I. No matter how many times I reboot these numbers maintain given I always reboot into 2.4.29.
STEP 2: I reboot into my Debian system, using 2.6.10 kernel, and
now kernel logs show 301 number, as does hdparm -I. But hdparm -i shows the 299 number.
STEP 3: I reboot again into my Debian system. This time all
places show the 301 number: the kernel logs, hdparm -i and -I.
STEP 4: I reboot into my 2.4.19 kernel, and this time ALL places,
again, show the 301 number. No matter how many times I reboot into 2.4.29 again or even 2.6 (Debian), these numbers doesn't change.
I've done the same but starting from full power-off into Debian,
and the things went like if we start from STEP 2 above. The only thing I've seen in the Debian logs that may explain this problem are:
current capacity is 156299375
native capacity is 156301488
But I don't know why this happens...
The disk (Seagate ST380021A, 80GB, UDMA100) is not showingsymptoms of a coming failure, it works ok and no data corruption has happened (yet...), but I'm worried.
Is this a known issue of 2.4 kernels? Am I doing anything wrong?
Any other detail about hardware, logs, etc. you must know? Thanks a lot in advance :)))
Raúl Núñez de Arenas Coronado
Signature · 3 lines
Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to...
Quoted 35 lines · DervishD
Hi all :)
I'm resending this because although it doesn't seem to imply a
hard disk failure, I have to repartition this disk and I must do it using a 2.6 kernel (long story), and I'm afraid that afterwards I cannot access the last sectors using 2.4 (since sometimes the disk is detected as being 2103 sectors smaller. I would appreciate any help, or if someone could point me to a source of information or a more appropriate mailing list.I'm having a problem with my primary hard disk: it inconsistently
reports the number of addressable LBA sectors. At times it reports 156301488 (let's call it '301' from now on) which is the correct one (I think) and other times it reports 156299375 (I'll call this one 299 from now on), a difference of 2103 sectors. But this is not arbitrary, I have reproduced the problem. I've done it using a self-compiled 2.4.29 kernel and a 2.6.10-1-k7 kernel from Debian unstable. These are the steps:STEP 1: From a fully powered off machine, I boot into my 2.4.29
kernel. The kernel log shows the 299 number, as well as does both hdparm -i and hdparm -I. No matter how many times I reboot these numbers maintain given I always reboot into 2.4.29.STEP 2: I reboot into my Debian system, using 2.6.10 kernel, and
now kernel logs show 301 number, as does hdparm -I. But hdparm -i shows the 299 number.STEP 3: I reboot again into my Debian system. This time all
places show the 301 number: the kernel logs, hdparm -i and -I.STEP 4: I reboot into my 2.4.19 kernel, and this time ALL places,
again, show the 301 number. No matter how many times I reboot into 2.4.29 again or even 2.6 (Debian), these numbers doesn't change.
Quoted 6 lines
I've done the same but starting from full power-off into Debian,
and the things went like if we start from STEP 2 above. The only thing I've seen in the Debian logs that may explain this problem are:current capacity is 156299375 native capacity is 156301488
Hard drives have a feature that can reserve a certain amount of space away from the user.
Linux IDE often does 'set max' to make 100% of the hard drive visible to the OS.
Jeff
Hi Jeff :)
Thanks for your answer, Jeff :))
* Jeff Garzik <[email protected]> dixit:
Quoted 5 lines
Quoted 2 lines · DervishD
current capacity is 156299375 native capacity is 156301488Hard drives have a feature that can reserve a certain amount of space away from the user.
Yes, I know, but the problem is that 2.4 kernels *does* reserve
that space but 2.6 certainly not, and if I boot into 2.6 and then reboot into 2.4, then 2.4 *does NOT* reserve that space.
By the way, the 'current capacity' is reported as the above only
if I boot into 2.4 from power off. As soon as I boot into 2.6, the drive seems to be reporting the second number as the current capacity (capacity_2). I've check the code in 2.4.29 and the difference between the setmax capacity and the capacity_2 only happens in that case, when cold booting into 2.4. Anytime 2.6 is involved, the drive reports the same capacity in both calls (idedisk_read_native_max_address_ext() and the one that gives lba_capacity_2 its value).
Quoted 2 lines
Linux IDE often does 'set max' to make 100% of the hard drive visible to the OS.
See the paragraph above: if I partition the disk under 2.6 the
partition will have a bigger address than the one that will be available under 2.4, and that can give errors while accessing that extra sectors. What can I do? For technical limitations in my box, I have to use 2.6 for repartitioning that disk (and I will be doing that in less than a month) and this will lead to unaccesible sectors when I boot back into my usual 2.4 kernel :(
Moreover, I've googled a bit and my disk doesn't seem to have
this problem, so I'm worried about a disk failure :(
Thanks again for your help, Jeff.
Raúl Núñez de Arenas Coronado
Signature · 3 lines
Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to...
Quoted 11 lines · DervishD
Quoted 6 lines
Quoted 2 lines · DervishD
current capacity is 156299375
native capacity is 156301488Hard drives have a feature that can reserve a certain amount of space away from the user.
Yes, I know, but the problem is that 2.4 kernels *does* reserve
that space but 2.6 certainly not, and if I boot into 2.6 and then reboot into 2.4, then 2.4 *does NOT* reserve that space.
Yes. It is normal...
Quoted 7 lines
See the paragraph above: if I partition the disk under 2.6 the
partition will have a bigger address than the one that will be available under 2.4, and that can give errors while accessing that extra sectors. What can I do? For technical limitations in my box, I have to use 2.6 for repartitioning that disk (and I will be doing that in less than a month) and this will lead to unaccesible sectors when I boot back into my usual 2.4 kernel :(
(1) You do not have to create partition over full disk.
(2) If you'll build your 2.4.x kernel with CONFIG_IDEDISK_STROKE=y ('Auto-Geometry Resizing support'), I bet that your problems with 2.4.x kernels disappear.
Petr
Hi Petr :)
Thanks for your answer :)
* Petr Vandrovec <[email protected]> dixit:
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines · DervishD
current capacity is 156299375
native capacity is 156301488Hard drives have a feature that can reserve a certain amount of space away from the user.
Yes, I know, but the problem is that 2.4 kernels *does* reserve
that space but 2.6 certainly not, and if I boot into 2.6 and then reboot into 2.4, then 2.4 *does NOT* reserve that space.Yes. It is normal...
I'm surprised :??? Does 2.6 'stroking' by default? I supposed
that maybe Debian people had activated stroking...
Quoted 8 lines
Quoted 7 lines
See the paragraph above: if I partition the disk under 2.6 the
partition will have a bigger address than the one that will be available under 2.4, and that can give errors while accessing that extra sectors. What can I do? For technical limitations in my box, I have to use 2.6 for repartitioning that disk (and I will be doing that in less than a month) and this will lead to unaccesible sectors when I boot back into my usual 2.4 kernel :((1) You do not have to create partition over full disk.
I would prefer to do it. Otherwise I have to calculate where the
partition must end in order to not disturb the kernel. Moreover, in that space will go the swap partition, probably...
Quoted 3 lines
(2) If you'll build your 2.4.x kernel with
CONFIG_IDEDISK_STROKE=y('Auto-Geometry Resizing support'), I bet that your problems with 2.4.x kernels disappear.
I'll try right now... YES, it works!. I don't understand, my BIOS
is AMI, not Awards, and I assumed that the stroke option was used only for Awards BIOS'es. I've looked at the code in the kernel and it doesn't seem to be particular for Award :?? It should be specified in the documentation.
Thanks a lot for your suggestion and for solving my problem :)
Raúl Núñez de Arenas Coronado
Signature · 3 lines
Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to...