linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eddie <stunnel@attglobal.net>
Cc: Grant Grundler <grundler@google.com>, linux-scsi@vger.kernel.org
Subject: Re: Should I be Worried: sda: p1 size .... limited to end of disk
Date: Tue, 13 Oct 2009 17:48:50 -0700	[thread overview]
Message-ID: <4AD51FF2.50900@attglobal.net> (raw)
In-Reply-To: <4AD38BEA.4090202@attglobal.net>

Eddie wrote:
> The raw partition table entry is:
>
> 00 01 01 00 8E FE FF FF 3F 00 00 00 84 E4 A8 AE
>
> Active Flag = 00
> Starting Head = 01
> Starting Cylinder = 0001
> Partition Type = x'8E' - Linux LVM
> Ending Head = x'FE' - 254
> Ending Cylinder/Sector = x'FFFF' - LBA
> Offset to Start = x'0000003F' - 63
> # of Sectors = x'AEA8E484' - 2930304132 - Hmmmmmmm
>
> So, that looks like the culprit.  Now, how did it happen.  I know I 
> can, sort of safely, rebuild that, by running (c)fdisk and making sure 
> I start the partition at exactly the same point.  But all I did the 
> first time, was use cfdisk, and allocate the complete disk to the 1st 
> primary partition.
OK, I recreated the partition table, trying both fdisk and cfdisk.  I'm 
still not sure how the original had the wrong values in there.  I guess 
that will remain a mystery.


fdisk -l -u /dev/sda

Disk /dev/sda: 1499.9 GB, 1499999502336 bytes
255 heads, 63 sectors/track, 182364 cylinders, total 2929686528 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x0003d809

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63  2929677659  1464838798+  8e  Linux LVM


OK, the total sectors seems to match the hardware scan -> sd 4:1:0:0: 
[sda] 2929686528 512-byte hardware sectors: (1.49 TB/1.36 TiB)

But 255 * 63 * 182364 = 2929677660.  What's this discrepancy due to.  
Does the drive report ALL sectors, even the ones used to replace "bad" ones.

However, 2929677660 does seem to tie up quite nicely with the "end 
sector", from the fdisk, so I'm assuming that everything is now correct.

Well, apart from the fact that LVM reports a Total PE allocation of 
357627 extents, which maps to 1464840192 Blocks, according to my maths 
anyway, which happens to be bigger than the "available" sectors on the 
disk.  I guess it's time to hit the LVM list, to see if there's any way 
I can safely correct this, before anything tries to use the "phantom" 
sectors.

Cheers,
Eddie




  reply	other threads:[~2009-10-14  0:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-10 19:45 Should I be Worried: sda: p1 size .... limited to end of disk Eddie
2009-10-12 19:04 ` Grant Grundler
2009-10-12 20:04   ` Eddie
2009-10-14  0:48     ` Eddie [this message]
2009-10-14 19:38       ` Grant Grundler

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=4AD51FF2.50900@attglobal.net \
    --to=stunnel@attglobal.net \
    --cc=grundler@google.com \
    --cc=linux-scsi@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).