Hide Forgot
Description of problem: After resizing a MCSG package LV, the LV appears to get corrupted requiring an fsck when MCSG trys to start a package on another cluster node. Version-Release number of selected component (if applicable): How reproducible: reproducable Steps to Reproduce: 1. resize a MCSG package LV 2. halt package 3. start package on another cluster node. Actual results: from the package log file (on the cluster node starting the package): Jul 16 12:30:32 root@NodeName master_control_script.sh[9313]: ###### Starting package oracle_SID ###### Jul 16 12:30:32 root@NodeName volume_group.sh[9395]: Attempting to addtag to vg vg_oracle_SID... Jul 16 12:30:33 root@NodeName volume_group.sh[9395]: addtag was successful on vg vg_oracle_SID. Jul 16 12:30:33 root@NodeName volume_group.sh[9395]: Activating volume group vg_oracle_SID . Jul 16 12:30:33 root@NodeName filesystem.sh[9471]: Checking filesystems: /dev/vg_oracle_SID/lv_1 /dev/vg_oracle_SID/lv_2 /dev/vg_oracle_SID/lv_3 /dev/vg_oracle_SID/lv_4 e2fsck 1.39 (29-May-2006) /dev/vg_oracle_SID/lv_1: clean, 26/640000 files, 607201/1280000 blocks e2fsck 1.39 (29-May-2006) /dev/vg_oracle_SID/lv_2: clean, 19/1281696 files, 1057553/2560000 blocks e2fsck 1.39 (29-May-2006) The filesystem size (according to the superblock) is 258048 blocks The physical size of the device is 129024 blocks Either the superblock or the partition table is likely to be corrupt! Abort? yes Jul 16 12:30:34 root@NodeName filesystem.sh[9471]: ERROR: Function sg_check_and_mount Jul 16 12:30:34 root@NodeName filesystem.sh[9471]: ERROR: Failed to fsck /dev/vg_oracle_SID/lv_3. e2fsck 1.39 (29-May-2006) /dev/vg_oracle_SID/lv_4: clean, 159/1537088 files, 1017168/3072000 blocks Jul 16 12:30:34 root@NodeName filesystem.sh[9471]: ERROR: Function sg_check_and_mount Jul 16 12:30:34 root@NodeName filesystem.sh[9471]: ERROR: Preceeding fsck call failed Jul 16 12:30:34 root@NodeName master_control_script.sh[9313]: ##### Failed to start package oracle_SID, ro llback steps ##### Jul 16 12:30:35 root@NodeName volume_group.sh[9571]: Deactivating volume group vg_oracle_SID Jul 16 12:30:36 root@NodeName volume_group.sh[9571]: Attempting to deltag to vg vg_oracle_SID... Jul 16 12:30:36 root@NodeName volume_group.sh[9571]: deltag was successful on vg vg_oracle_SID. Expected results: package should start without problem Additional info: Two work-arounds: Halting multipathd on the node before starting the package running vg
perhaps a bit late to be asking, but can you show the LVM and file system information before the move is attempted? (e.g. 'pvs', 'vgs', 'lvs', 'df -Th') I'd like to see how the LVs and file system are laid out. Then, after the failed move, could you repeat the commands on the other node? (You should be able to get the LVM information even if you can't get the FS info.)
Yes, it's a 'little' too late to ask. That cluster was decommissioned and replaced with a RHCS on RHEL 6.3 cluster. Two and a half years.
(In reply to Mark McDonald from comment #2) > Yes, it's a 'little' too late to ask. That cluster was decommissioned and > replaced with a RHCS on RHEL 6.3 cluster. Two and a half years. We're really sorry for that, that was an oversight for this bug report.