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

Re: [linux-lvm] df doesn't display increased available disk space



Robert,
    You need to change one of the top most levels (filesystem).  Read this
next part from the bottom up (Everyone: if I have something here
wrong, let me know)

Highest Level:  File System layer (files & directories)
                LVM LV Layer (logical volumes)
                LVM PV layer (physical volumes)
                Partition table (special data on the hard disk)
                LBA translation (in disk controller or drive circutry)
Lowest Level:   Physical Hard disk (platter that spins & r/w heads)

    OK, so like it sounds like you've added more space to the LVM PV
layer.  So like you need to add it to the LVM LV layer, and then you
need to change the file system size to take advantage of the increased
LVM LV space that you've added.

   Clear as mud, right?

On Fri, March 4, 2005 13:40, Erik Ohrnberger said:
> Robert,
>     When you say type 8e, it makes me think of the partition table, not
> the filesystem, which would be etx2 or etx3 or XFS or Reiserfs or ....
>
>     Now when a partition is marked as type 8e, it is an LVM partition.
>
>     Best of luck,
>         Erik.
>
> On Fri, March 4, 2005 13:35, Robert Buick said:
>> I'm using type 8e, does anyone happen to know if resize2fs is
>> appropriate for this type; the man page only mentions type2.
>>
>>
>> On Thu, 2005-03-03 at 21:47 +0000, Robin Green wrote:
>>> On Thu, Mar 03, 2005 at 09:35:55PM +0000, Robert Buick wrote:
>>> > I'm running Fedora Core 3 with LVM2, and have added /dev/hda4
>>> (13.09GB)
>>> > to the VG, however this increase is not reflected if I do a df -h.
>>> Have
>>> > I missed something?
>>> >
>>> >[root stemme mapper]# lvscan
>>> > ACTIVE            '/dev/VolGroup00/LogVol00' [34.53 GB] inherit
>>> >  ACTIVE            '/dev/VolGroup00/LogVol01' [1.94 GB] inherit
>>> > [root stemme mapper]# pvscan
>>> >  PV /dev/hda2   VG VolGroup00   lvm2 [23.41 GB / 32.00 MB free]
>>> > PV /dev/hda4   VG VolGroup00   lvm2 [13.09 GB / 0    free]
>>> > Total: 2 [36.50 GB] / in use: 2 [36.50 GB] / in no VG: 0 [0   ]
>>> > [root stemme mapper]# vgscan
>>> >  Reading all physical volumes.  This may take a while...
>>> >  Found volume group "VolGroup00" using metadata type lvm2
>>> > [root stemme mapper]# df -h
>>> > Filesystem            Size  Used Avail Use% Mounted on
>>> > /dev/mapper/VolGroup00-LogVol00
>>> >                       22G  9.0G   12G  45% /
>>> > /dev/hda1              99M   22M   73M  23% /boot
>>> > none                  760M     0  760M   0% /dev/shm
>>
>>> Yes - you need to resize the filesystem as well.
>>>
>>> If you are using an ext2 or ext3 filesystem you could use resize2fs. If
>>> you
>>> are using reiserfs, you could use resize_reiserfs. I don't know about
>>> resize
>>> tools for other filesystems.
>>>
>>> Please note that resize2fs in Fedora Core 3 is buggy, and may corrupt
>>> the
>>> resize inode. To get a version that works better, I recommend you
>>> download and build
>>> from source e2fsprogs 1.36 from
>>> http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.36.tar.gz
>>>
>>> (If you wanted to avoid using resize2fs altogether, you could of course
>>> backup all your data in /, mke2fs the root filesystem, and copy all the
>>> data
>>> back again. But that would be much slower.)
>>
>>
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm redhat com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm redhat com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>



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