All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: DervishD <lkml@dervishd.net>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND] Hard disk LBA sector count is not always the same
Date: Mon, 23 May 2005 14:31:17 -0400	[thread overview]
Message-ID: <42922175.8090005@pobox.com> (raw)
In-Reply-To: <20050523121424.GB339@DervishD>

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




  reply	other threads:[~2005-05-23 18:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-23 12:14 [RESEND] Hard disk LBA sector count is not always the same DervishD
2005-05-23 18:31 ` Jeff Garzik [this message]
2005-05-23 20:02   ` DervishD
2005-05-23 22:21     ` Petr Vandrovec
2005-05-24  7:14       ` DervishD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42922175.8090005@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@dervishd.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.