On 18.3.2012 18:53, John R Pierce wrote:

On 03/18/12 10:34 AM, madunix@gmail.com wrote:

...

I need to shrink /home(755G) to 150GB and use free space to add to the existing /(50G). #df -kh Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_web-lv_root 50G 7.8G 40G 17% / tmpfs 7.8G 384K 7.8G 1% /dev/shm /dev/sda2 485M 79M 381M 18% /boot /dev/sda1 200M 256K 200M 1% /boot/efi /dev/mapper/vg_web-lv_home755G 6.2G 711G 1% /home

Need to have the step, can this be done online or need to go offline (umount) the file systems.

IMHO, the only sane way to shrink a file system is to back it up to other media, delete it, then recreate it at the new smaller size and restore the backup.

Thats a safe way to do it. Anyway, regardless of how the goal will be achieved, I agree that a restorable backup should exist.

On Sun, Mar 18, 2012 at 08:04:14PM +0100, Markus Falb wrote:

On 18.3.2012 18:34, madunix@gmail.com wrote:

...

I need to shrink /home(755G) to 150GB and use free space to add to the existing /(50G). #df -kh Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_web-lv_root 50G 7.8G 40G 17% / tmpfs 7.8G 384K 7.8G 1% /dev/shm /dev/sda2 485M 79M 381M 18% /boot /dev/sda1 200M 256K 200M 1% /boot/efi /dev/mapper/vg_web-lv_home755G 6.2G 711G 1% /home

Need to have the step, can this be done online or need to go offline (umount) the file systems.

What filesystem? Assuming ext3, this cannot shrunk without unmounting. I believe the following *should* work for ext3

$ umount /home $ e2fsck -f /dev/vg_web/lv_home $ resize2fs /dev/vg_web/lv_home 150g $ lvresize -L 150g /dev/vg_web/lv_home $ mount /home

I am not sure how safe it is. Take care!

I was under the impression that you needed to unmount the file system to shrink it with resize2fs (you can grow it online however).

Ray

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 ?

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@fasel.at 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@centos.org http://lists.centos.org/mailman/listinfo/centos

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 3/20/2012 5:25 AM, Markus Falb wrote:

On 19.3.2012 10:14, Peter Kjellström wrote:

...

On Sunday 18 March 2012 19.40.21 Ray Van Dolson wrote:

...

On Sun, Mar 18, 2012 at 08:04:14PM +0100, Markus Falb wrote:

...

...

...

What filesystem? Assuming ext3, this cannot shrunk without unmounting. I believe the following *should* work for ext3

$ umount /home $ e2fsck -f /dev/vg_web/lv_home $ resize2fs /dev/vg_web/lv_home 150g $ lvresize -L 150g /dev/vg_web/lv_home $ mount /home

I am not sure how safe it is. Take care!

...

I'd like to add that it's probably good paranoia not to size the lv down too tightly (should it happen to become smaller than the fs then ooops). That is, I'd size the lv down to a comfortable margin above the fs size (and then size the fs up to the device size).

Hmm. I did that too a couple of times in the past. But why? What are the reasons for the paranoia?

I think he means don't resize/shrink the filesystem *and* the LVM LV to the exact same size. If the LVM lvresize command were to truncate the end of the existing filesystem, now you have issues.

Instead do this: first shrink the filesystem a little smaller than you want, then resize the LVM LV down to the desired size, then resize the filesystem again to grow to use the remaining space. This way you ensure you don't snip of the end of the filesystem.

# umount /home # e2fsck -f /dev/vg_web/lv_home # resize2fs /dev/vg_web/lv_home 149g # lvresize -L 150g /dev/vg_web/lv_home # resize2fs /dev/vg_web/lv_home (will default to the LV size of 150g) # mount /home

- -- David Goldsmith