Increasing the size of a LV (Logical Volume) is somewhat trivial. Reducing the size isn't. Its important to not make the LV smaller than the filesystem it contains. There is usually confusion as to what exactly '1G' is. So not wanting to trust that the option '70G' is the same for both resize2fs and lvreduce, I opted to:
- resize the filesystem such that its much smaller than the desired LV size
- resize the LV to the desired size (must always be greater/equal the filesystem size!)
- use 'resize2fs' with no size to automatically fill the resized LV
root@orbit:~# e2fsck -f /dev/main/backup
e2fsck 1.38 (30-Jun-2005)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/main/backup: ***** FILE SYSTEM WAS MODIFIED *****
/dev/main/backup: 560509/17039360 files (0.5% non-contiguous), 17470436/34078720 blocks
root@orbit:~# resize2fs /dev/main/backup 70G
resize2fs 1.38 (30-Jun-2005)
Resizing the filesystem on /dev/main/backup to 18350080 (4k) blocks.
The filesystem on /dev/main/backup is now 18350080 blocks long.
root@orbit:~# lvreduce -L80G main/backup
WARNING: Reducing active logical volume to 80.00 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce backup? [y/n]: y
Reducing logical volume backup to 80.00 GB
Logical volume backup successfully resized
root@orbit:~# resize2fs /dev/main/backup
resize2fs 1.38 (30-Jun-2005)
Resizing the filesystem on /dev/main/backup to 20971520 (4k) blocks.
The filesystem on /dev/main/backup is now 20971520 blocks long.
Done... and not surprisingly, 'df -h' reports the size as 79G instead (although it could be excluding filesystem overhead)
root@orbit:~# mount /backup/
root@orbit:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/main-backup 79G 65G 15G 83% /backup
Easy, and the data is still intact.
No comments:
Post a Comment