Hi
TESTDB1 has DB storage and backup storage.
I add backup disk to backup filesystem.
I don't know why, but server want to e2fsck.
OS version is Red Hat Enterprise Linux Server release 6.4 (Santiago).


[root@TESTDB1 bin]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 58G 19G 36G 35% /
tmpfs 32G 371M 32G 2% /dev/shm
/dev/sda1 194M 58M 127M 32% /boot
/dev/sda2 97G 3.4G 88G 4% /data001
/dev/sda6 105G 20G 80G 20% /data002
/dev/mapper/UNT319_VG01-engnlv01
50G 38G 9.3G 81% /engn001
/dev/mapper/UNT319_VG01-logslv01
50G 5.5G 42G 12% /logs001
/dev/mapper/UNT319_VG01-bkuplv01
99G 45G 49G 49% /bkup001
/dev/mapper/SIMPANA_VG-SIMPANA_LV
7.3T 6.7T 170G 98% /simpana_bk
[root@TESTDB1 bin]$ umount /simpana_bk
[root@TESTDB1 bin]$ resize2fs /dev/mapper/SIMPANA_VG-SIMPANA_LV
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/mapper/SIMPANA_VG-SIMPANA_LV' first.

[root@TESTDB1 bin]$ e2fsck -f /dev/mapper/SIMPANA_VG-SIMPANA_LV
e2fsck 1.41.12 (17-May-2010)
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/mapper/SIMPANA_VG-SIMPANA_LV: 13585/491593728 files (2.9% non-contiguous), 1823669136/1966371840 blocks
[root@TESTDB1 bin]$ resize2fs /dev/mapper/SIMPANA_VG-SIMPANA_LV
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/mapper/SIMPANA_VG-SIMPANA_LV to 2097443840 (4k) blocks.
The filesystem on /dev/mapper/SIMPANA_VG-SIMPANA_LV is now 2097443840 blocks long.
[root@TESTDB1 bin]$ mount /simpana_bk
[root@TESTDB1 bin]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 58G 19G 36G 35% /
tmpfs 32G 371M 32G 2% /dev/shm
/dev/sda1 194M 58M 127M 32% /boot
/dev/sda2 97G 3.4G 88G 4% /data001
/dev/sda6 105G 20G 80G 20% /data002
/dev/mapper/UNT319_VG01-engnlv01
50G 38G 9.3G 81% /engn001
/dev/mapper/UNT319_VG01-logslv01
50G 5.5G 42G 12% /logs001
/dev/mapper/UNT319_VG01-bkuplv01
99G 45G 49G 49% /bkup001
/dev/mapper/SIMPANA_VG-SIMPANA_LV
7.7T 6.7T 637G 92% /simpana_bk



After resizing filesystem, CPU wait I/O is 30% increasing and sda5(swap) busy % keep 100% utilization during 12 hours
(Before those utilization are lower than 10%)
After was instance restart,strangely... I/O and swap busy(%) are 0%

e2fsck has bug or not???

Is the new disk you added to Volume Group, SIMPANA_VG, the same kind as the existing ones? e.g. If the existing ones are SAN disks is the new one from the same SAN disk array and presented via the same SAN switches? Dissimilar disks could cause issues as the entire VG may only run at the speed of its slowest disk.

What is your entry for simpana_bk in /etc/fstab? Is this an ext2, ext3 or ext4 disk there? ext2 is not journaled so shouldn't really be used. ext3 had odd performance issues in some situations (such as deleting all files or running fsck). Ideally you'd want to run ext4 as it performs very well on RHEL6/RHEL7.

Are any (or all of the disks) in the VG under multipath control (e.g. native Linux multipathd, EMC PowerPath)?

So ... what is your problem?
I am sure it has many bugs, but since it didn't change anything on your filesystem, I have strong doubts that the temporary increase in CPU wait time was related.

Let me speculate: Since the volume size has increased, filesystem or LVM code (is this a RAID volume?) saw an opportunity to rebalance some data, which caused a temporary increase in disk access.

Of course, this is just guessing. Since your system looks good now, it's impossible to investigate what happened before the reboot.

Next time you post something, please put commands and their input and output between code tags for better readability.

Sounds like it might have been the ext4 lazy init proceeding in the background when the expanded filesystem was first mounted. I'm not certain this happens for a resize (as opposed to creating a new filesystem), but it sounds likely. Examining the filesystem flags while the unusual activity was happening would be the only way to be sure.