Re: LVM

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



Done!

Attention: Shrink/Extend a filesystem may damage the data on it, pls backup
date before.

1. Decrease /dev/mapper/vg_web-lv_home
   # umount /dev/mapper/vg_web-lv_home
   # e2fsck -f /dev/mapper/vg_web-lv_home
   # resize2fs /dev/mapper/vg_web-lv_home  <size>
   # lvresize -L <size> /dev/mapper/vg0-lv_home
   # mount -o remount /home

check the size of /dev/mapper/vg_web-lv_home with "df -kh"

2. Increase /dev/mapper/vg_web-lv_root
   # lvresize -L <size> /vg_web-lv_root
   # resize2fs /vg_web-lv_root

check the size of /dev/mapper/vg_web-lv_root with "df -kh"


df -kh
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_websdc-lv_root
                      296G  7.1G  274G   3% /
tmpfs                 7.8G  176K  7.8G   1% /dev/shm
/dev/sda2             485M   84M  377M  19% /boot
/dev/sda1             200M  256K  200M   1% /boot/efi
/dev/mapper/vg_websdc-lv_home
                       99G  6.3G   88G   7% /home


Thanks.











On Tue, Mar 20, 2012 at 12:04 PM, Markus Falb <markus.falb@xxxxxxxx> wrote:
>
> On 19.3.2012 10:16, John R Pierce wrote:
> > On 03/19/12 2:14 AM, Peter Kjellström wrote:
> >> I can also add that I've successfully managed to shrink ext3 before
but a
> >> verified backup is probably good advice..
> >
> > does resize2fs relocate blocks or is it restricted to shrinking only to
> > last high water block in use ?
>
> I found this in resize/resize2fs.c.unused_group_blocks
>
> /*
>  * Resizing a filesystem consists of the following phases:
>  *
>  *      1.  Adjust superblock and write out new parts of the inode
>  *              table
>  *      2.  Determine blocks which need to be relocated, and copy the
>  *          contents of blocks from their old locations to the new ones.
>  *      3.  Scan the inode table, doing the following:
>  *              a.  If blocks have been moved, update the block
>  *                      pointers in the inodes and indirect blocks to
>  *                      point at the new block locations.
>  *              b.  If parts of the inode table need to be evacuated,
>  *                      copy inodes from their old locations to their
>  *                      new ones.
>  *              c.  If (b) needs to be done, note which blocks contain
>  *                      directory information, since we will need to
>  *                      update the directory information.
>  *      4.  Update the directory blocks with the new inode locations.
>  *      5.  Move the inode tables, if necessary.
>  */
>
> --
> Kind Regards, Markus Falb
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux