1. Basic knowledge
EXT4 file system can be enlarged/extended or shrunk by its design. Because an ext4 file system is built inside a partition/Logical Volume, so
- When extending, LV must be extended first, then EXT4 fs can be extended.
- When shrinking, EXT4 must be shrunk first, then LV can be shrunk.
Extending a file system is kind of safe while shrinking one is dangerous. So be more careful when shrinking an ext4 fs.
2. Non-Root ext4 file system
2.1 extending
EXT4 supports online extending.
# Extend LV by 1GB first
lvresize -L +1G /dev/vg0/lv1
# Extend ext4 then
resize2fs /dev/vg0/lv1
------------------ OR------------------
# The -r option tells lvresize to extend fs after extending lv
# automatically
lvresize -r -L +1G /dev/vg0/lv1
2.2 shrinking (It's best to backup all data before shrinking)
# unmount file system, resize2fs: On-line shrinking not supported
umount /dev/vg0/lv1
# fsck fs
fsck /dev/vg0/lv1
# Shrink file system first
resize2fs /dev/vg0/lv1 3G
# Shrink LV then, there will be a warning: THIS MAY DESTROY YOUR
# DATA, Do you really want to reduce?
# Make sure the size(LV) >= size(FS), or the FS will be corrupted!!!
lvresize -L 3G /dev/vg0/lv1
# check fs again
e2fsck /dev/vg0/lv1
# remount the shrunken fs
mount /dev/vg0/lv1 /mnt/lv1
------------------ OR------------------
# The -r option tells lvresize to umount, shrink the fs first
# then shrinking LV underhood automatically.
lvresize -r -L 3G /dev/mapper/vg-lv1
root@server1 ~]# lvresize -r -L 4G /dev/vg0/lv1
Do you want to unmount "/mnt/lv1" ? [Y|n] y
fsck from util-linux 2.23.2
/dev/mapper/vg0-lv1: 11/294912 files (0.0% non-contiguous), 38998/1179648 blocks
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/vg0-lv1 to 1048576 (4k) blocks.
The filesystem on /dev/mapper/vg0-lv1 is now 1048576 blocks long.
Size of logical volume vg0/lv1 changed from 4.50 GiB (1152 extents) to 4.00 GiB (1024 extents).
Logical volume vg0/lv1 successfully resized.
If the LV'size is less than FS, the FS will be broken.
[root@server1 ~]# fsck /dev/vg0/lv1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
The filesystem size (according to the superblock) is 786432 blocks
The physical size of the device is 760832 blocks
Either the superblock or the partition table is likely to be corrupt!
At this moment, if the shrunken LV has not been used, we can enlarge the LV back to make its size larger than the FS. But it doesn't guarantee the FS will be recovered.
We can find that the "lvresize -r" option really helps as it guarantees the FS will not be corrupted.
3. Root ext4 file system
When resizing a ROOT file system, the situation becomes more complicated. We must be much more careful as the whole OS may fail to boot when the root fs is broken!!!
3.1 extending
Actually, extending a root ext4 FS is the same as extending a non-root one. It's able to extend fs to be larger than the LV underhood, which means you cannot break/corrupt file system by 'resize2fs' command only.
[root@server1 ~]# resize2fs /dev/vg0/lv1 5G
resize2fs 1.42.9 (28-Dec-2013)
The containing partition (or device) is only 1048576 (4k) blocks.
You requested a new size of 1310720 blocks.
So we can conclude, extending an ext4 file system is safe, even for root fs.
3.2 shrinking root LV by accident?
DO NOT TRY TO SHRINK A ROOT LV/FS UNLESS YOU HAVE TO AND YOU KNOW WHAT YOU DO.
Since ext4 doesn't support online shrinking, you must unmount it first. However, you cannot unmount the ROOT fs when Linux is running normally.
3.2.1 What can we do if shrinking the root LV by accident?
If we only shrink a little, the OS may not notice it right away.
[root@system1 ~]# lvresize -L -3G /dev/centos/root
WARNING: Reducing active and open logical volume to 14.00 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce centos/root? [y/n]: y
Size of logical volume centos/root changed from 17.00 GiB (4352 extents) to 14.00 GiB (3584 extents).
Logical volume centos/root successfully resized.
If we only shrink more, the OS would give mem error like below.
root@system1 ~]# lvresize -L -4G /dev/centos/root
WARNING: Reducing active and open logical volume to 10.00 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce centos/root? [y/n]: y
Size of logical volume centos/root changed from 14.00 GiB (3584 extents) to 10.00 GiB (2560 extents).
[ 170.842674] attempt to access beyond end of device
[ 170.844527] dm-0: rw=1, want=25432984, limit=20971520
[ 170.846547] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error -5 writing to inode 786587 (offset 0 size 4096 starting block 3179122)
[ 170.851635] Buffer I/O error on device dm-0, logical block 3179122
[ 170.853873] JBD2: Detected IO errors while flushing file data on dm-0-8
[ 170.857547] attempt to access beyond end of device
[ 170.859650] dm-0: rw=1, want=25662280, limit=20971520
[ 170.864506] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error -5 writing to inode 786531 (offset 0 size 4096 starting block 3207784)
[ 170.870122] Buffer I/O error on device dm-0, logical block 3207784
Logical volume centos/root successfully resized.
[root@system1 ~]# [ 176.163428] JBD2: Detected IO errors while flushing file data on dm-0-8
At this point, actually, the root fs is already broken. But we may recover it.
[root@system1 ~]# lvresize -L +7G /dev/centos/root
Couldn't create temporary archive name.
Since the ROOT fs is not working well now, lvm cannot write backup files to /etc/ which is located on the root fs as well.
We can use '-An' option to avoid writing the backup config.
[root@system1 ~]# lvresize -An -L +7G /dev/centos/root
Size of logical volume centos/root changed from 10.00 GiB (2560 extents) to 17.00 GiB (4352 extents).
WARNING: This metadata update is NOT backed up.
Logical volume centos/root successfully resized.
Thank goodness, our root LV comes back.
3.2.2 What if we reboot the OS after shrinking root LV by accident?
[ 7.946603] EXT4-fs (dm-0): bad geometry: block count 4325376 exceeds size of device (2621440 blocks)
[FAILED] Failed to mount /sysroot.
See 'systemctl status sysroot.mount' for details.
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Reload Configuration from the Real Root.
[ OK ] Stopped dracut pre-udev hook.
Stopping dracut pre-udev hook...
[ OK ] Stopped dracut cmdline hook.
Stopping dracut cmdline hook...
[ OK ] Stopped dracut initqueue hook.
Stopping dracut initqueue hook...
[ OK ] Stopped target Basic System.
[ OK ] Stopped target System Initialization.
[ OK ] Started Emergency Shell.
Sta
Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.
Your system failed!!!
If you try to extend the LV using lvm (which is available in initramfs) it doesn't work.
And there is no "resize2fs" command for us to shrink the root fs to meet the size of LV.
:/# lvm lvresize -L +7G /dev/centos/root
Read-only locking type set. Write locks are prohibited.
Can't get lock for centos
Cannot process volume group centos
This is because the locking_type variable in /etc/lvm/lvm.conf equals "4" by default.
- No Locking
- Local Locking
- External Locking
- Clustered Locking
- Read-Only Locking
- Dummy Locking
On a normal system, locking_type should be 1. So we change it to 1, and then:
:/# vi /etc/lvm/lvm.conf (change: locking_type=1)
:/# lvm lvresize -l +100%FREE /dev/centos/root
Size of logical volume centos/root changed from 10.00 GiB (2560 extents) to 17.00 GiB (4352 extents).
Logical volume centos/root successfully resized.
And then do a fsck:
:/# fsck /dev/centos/root
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/mapper/centos-root: recovering journal
/dev/mapper/centos-root contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix<y>? yes
Inode 399300 was part of the orphaned inode list. FIXED.
Deleted inode 399301 has zero dtime. Fix<y>? yes
Inode 399302 was part of the orphaned inode list. FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 786577
Connect to /lost+found<y>? yes
Inode 786577 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 786582
Connect to /lost+found<y>? yes
Inode 786582 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 786583
Connect to /lost+found<y>? yes
Inode 786583 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 786587
Connect to /lost+found<y>? yes
Inode 786587 ref count is 2, should be 1. Fix<y>? yes
Pass 5: Checking group summary information
Block bitmap differences: +34419 -3180034 -3180036 -3210243 -3210246
Fix<y>? yes
Free blocks count wrong for group #1 (21322, counted=21321).
Fix<y>? yes
Free blocks count wrong for group #97 (25567, counted=25571).
Fix<y>? yes
Free blocks count wrong (3969967, counted=3969936).
Fix<y>? yes
Inode bitmap differences: -(399299--399302)
Fix<y>? yes
Free inodes count wrong for group #48 (2106, counted=2110).
Fix<y>? yes
Free inodes count wrong for group #112 (8191, counted=8192).
Fix<y>? yes
Free inodes count wrong (1055109, counted=1055108).
Fix<y>? yes
/dev/mapper/centos-root: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/centos-root: 26236/1081344 files (0.2% non-contiguous), 355440/4325376 blocks
:/#
And then reboot the OS. Hopefully, the root fs is recovered!
3.3 The right way to shrink ROOT FS/LV
Although it's clear that shrinking a ROOT FS/LV is dangerous, some times it's a must-do-thing.
I haven't found a simple and perfect solution to this task. The following link may be of help.
4. Tips for EX200/EX300/EX294
- As file system may cause the Linux OS to fail, it's highly suggested you finish all disk/fs/lvm/iSCSI related questions at the very beginning. If something unexpected happens, at least we can rebuild the VM and still have enough time to finish the rest questions.
- If you cannot solve the issue, just skip these questions and leave your time to other questions. It's much better to pass the exam with low marks than to fail to reboot the VM and get 0 scores.
- Generally, the exams don't ask for shrinking ROOT FS/LV. Try to find free space by:
# check if existing VGs have free space
[root@server1 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
centos 1 2 0 wz--n- 18.00g 0
vg0 1 2 0 wz--n- 952.00m 0
# check if there are any PVs having free space
[root@server1 ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/vda2 centos lvm2 a-- 18.00g 0
/dev/vdc1 vg0 lvm2 a-- 952.00m 0
# list all disks and check if
# there is unallocated space for each disk
[root@server1 ~]# lsblk ('lsblk' does NOT list unpartationed sapce)
[root@server1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 20G 0 disk
├─vda1 252:1 0 2G 0 part /boot
└─vda2 252:2 0 18G 0 part
├─centos-root 253:0 0 15G 0 lvm /
└─centos-swap 253:1 0 3G 0 lvm [SWAP]
vdb 252:16 0 3G 0 disk
└─vdb1 252:17 0 1.9G 0 part
vdc 252:32 0 5G 0 disk
└─vdc1 252:33 0 953M 0 part
├─vg0-lv1 253:2 0 100M 0 lvm
└─vg0-lv2 253:3 0 852M 0 lvm
[root@server1 ~]
[root@server1 ~]# parted /dev/vda print free
[root@server1 ~]# parted /dev/vda print free
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
32.3kB 1049kB 1016kB Free Space
1 1049kB 2144MB 2143MB primary xfs boot
2 2144MB 21.5GB 19.3GB primary lvm
[root@server1 ~]# parted /dev/vdb print free
Model: Virtio Block Device (virtblk)
Disk /dev/vdb: 3221MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
17.4kB 1049kB 1031kB Free Space
1 1049kB 2000MB 1999MB primary
2000MB 3221MB 1222MB Free Space
[root@server1 ~]# parted /dev/vdc print free
Model: Virtio Block Device (virtblk)
Disk /dev/vdc: 5369MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
17.4kB 1049kB 1031kB Free Space
1 1049kB 1000MB 999MB
1000MB 5369MB 4368MB Free Space
In our example, we found 4.3GB free space on /dev/vdc and 1.2GB on /dev/vdb.
No comments:
Post a Comment