[RESEND] Hard disk LBA sector count is not always the same

[RESEND] Hard disk LBA sector count is not always the same

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

    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 showing
symptoms 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

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

Re: [RESEND] Hard disk LBA sector count is not always the same

[Jeff Garzik]

DervishD wrote:
>     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

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

Re: [RESEND] Hard disk LBA sector count is not always the same

[DervishD]

    Hi Jeff :)

    Thanks for your answer, Jeff :))

 * Jeff Garzik <jgarzik@pobox.com> dixit:
> DervishD wrote:
> >    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.

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

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

Re: [RESEND] Hard disk LBA sector count is not always the same

[Petr Vandrovec]

DervishD wrote:
>>DervishD wrote:
>>
>>>   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.
> 
> 
>     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...

>     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

Re: [RESEND] Hard disk LBA sector count is not always the same

[DervishD]

    Hi Petr :)

    Thanks for your answer :)

 * Petr Vandrovec <vandrove@vc.cvut.cz> dixit:
> >>DervishD wrote:
> >>>  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.
> >    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...
 
> >    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...
 
> (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

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