[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Missing Disk Space or Partition

On Mon, Jan 24, 2011 at 1:08 PM, Carl Johnson <carlj@peak.org> wrote:
RR <ranjtech@gmail.com> writes:

> On Mon, Jan 24, 2011 at 12:07 AM, Carl Johnson <carlj@peak.org> wrote:
>> RR <ranjtech@gmail.com> writes:
>> > I see as more messages are pouring in, this message is getting pushed
>> down
>> > further and people won't even see it anymore. Does anyone have a personal
>> > doco, blog , cheatsheet for modifying the disk label  (and then I'm
>> assuming
>> > I'll have to recreate my partition table) but not losing my data? I have
>> > done this sort of stuff of destroying the partition table and re-creating
>> it
>> > by hand before without losing the data but I'm just very unfamiliar with
>> > this LVM beast and was wondering if someone could help at all?
>> If it is just a lvm problem, then you should first try running pvs, vgs,
>> and lvs.  Those will tell you what LVM thinks that it has.  Also you
>> should run 'fdisk -l /dev/sda' (or whatever disks you have) to see what
>> partitions your system thinks it has.  Man lvm should give you some
>> general information on the lvm commands, but you will probably need to
>> read the individual man pages for more detail on the commands.
> Hello Carl,
> I've posted all of that in the past emails in this thread, however for the
> benefit of new people seeing this message (esp. those not using gmail with
> the conversation mode set on) here's the info again

Sorry, I must have missed that before.

> lvm> pvs
>   PV         VG           Fmt  Attr PSize  PFree
>   /dev/sda2  DebSparcx64-01 lvm2 a-   43.21G    0
> shows the main partition to be 43.21GB and if /dev/sda1 is boot and
> /dev/sda2 is the lvm volume and /dev/sda2 is the "whole disk", then
> how/where do I extend this volume to?
> # lvs
>   LV     VG           Attr   LSize   Origin Snap%  Move Log Copy%  Convert
>   home   DebSparcx64-01 -wi-ao  30.47G
>   root   DebSparcx64-01 -wi-ao 264.00M
>   swap_1 DebSparcx64-01 -wi-ao   4.66G
>   tmp    DebSparcx64-01 -wi-ao 380.00M
>   usr    DebSparcx64-01 -wi-ao   4.66G
>   var    DebSparcx64-01 -wi-ao   2.79G
> # fdisk -l /dev/sda
> Disk /dev/sda (Sun disk label): 24 heads, 424 sectors, 8922 cylinders
> Units = cylinders of 10176 * 512 bytes
>    Device Flag    Start       End    Blocks   Id  System
> /dev/sda1             0        19     96672    1  Boot
> /dev/sda2            19      8924  45308640   8e  Linux LVM
> /dev/sda3             0      8924  45405312    5  Whole disk
> as per the above, /sda2 is extending from cylinder 19 to the last cylinder
> but it's coming u to only 43.21GB? Where did the rest of it go?

Everything looks entirely consistent, but it appears that your disk is
only about 45GB.

 sda  = 24*424*8922 = 90790272 sectors (512 bytes) = 45395136KB = 43.29GB
 sda2 = 24*424*8905 = 90617280 sectors = 45308640KB = about 43.21GB

I do see a couple of thing that might cause problems other than that.
Using overlapping partitions could cause problems, but I am surprised
that is even allowed.  You currently have sda3 which overlaps (contains)
both sda1 and sda2.  It also appears that sda1 ends on cylinder 19, but
sda2 also starts on cylinder 19.  If they are actually using partial
cylinders that might make sense, but I have never seen it before.  I
also see that fdisk reports 8922 cylinders for the disk but assigns 8925
cylinders (0-8924) to the partitions.

So, in summary I don't see any missing disk space.  If your disks are
actually 72GB it appears that you will have to tell fdisk what the
actual size is, but I would be very careful about doing that.  If you
really can do that, then you can resize lvm (pvresize and lvresize) and
ext3 filesystems.  If you make any mistakes on any of those you will
almost certainly have damaged filesystems and likely lost data.
Hi Carl,
yes, it's all very weird and not sure how it's letting any other program even do this like overlapping cylinders and partial cylinders and what not. But rest assured, the disks are in fact 72G
# dmesg | grep -i seagate
[   87.602318] scsi 0:0:0:0: Direct-Access     SEAGATE  ST373207LSUN72G  045A PQ: 0 ANSI: 3
[   92.432095] scsi 0:0:1:0: Direct-Access     SEAGATE  ST373307LSUN72G  0707 PQ: 0 ANSI: 3
Now, from what I understand with these things, all of this could be a one big mess up of the partition table which is written in the "label" of the disk. If i create a new label using parted mklabel, then my parition table might be destroyed but if I note down the key information before hand i.e. what paritions/LV I have within my VG and where each of the VG and/or PV and LVs start/finish, then I could just rebuild the table and adjust the label to match the geometry because don't forget, the message you responded to, was basiclaly saying that even Parted knows that the Disk Label is not matching the Disk geometry that the OS is detecting. We need to make them consistent and it'll be fine.
Honestly, I'd rather just rebuild this machine, but I'm not there physically anymore and given the problems I had in installing Debian on that Sparc machine while I was actually there, if I have those again, when I'm now 8,000 miles away, that's going to be bad! On EVERY Sparc system that I have tried to install Debian on, I've had random issues and most of them have been fixed by removing/disconnecting physical hardware, the drivers of which could have been freezing up / crashing the system. Even the V100 I have in the lab here only worked after I disconnected the CD-ROM drive from the system. If I have that issue with one of the remote machines, I can't really conect/disconnect physical hardware being 8.000 miles away :( So I need to have a way to fix this manually if someone can help :(

Reply to: