Can't fsck mount points on storage

[chud67]

We did a scheduled reboot and fsck of a couple of servers and during reboot they would not complete the fsck of mount points on the EVA. They got to a certain percentage and stopped, and the server would not come up (RH Linux servers). We had to go load an fstab with only local mount points, no storage, and then the servers came up fine. Any ideas why this would happen? The EVA appears to be healthy. Nothing much in server's messages file.
This is the first time we have done a scheduled fsck on a server.

[Johan Guldmyr]

Hey, after server came back up - could you mount the EVA disks? Can you run a file system now?

Maybe there is actually something wrong with the data on the disk and not with the storage subsystem?

Or maybe there is something going on with the on-boot fsck?

[chud67]

Yes, after the server came up we uncommented the storage mount points in fstab and did a mount -a, and they came up fine.

[chud67]

In case it helps someone: per Red Hat, best practice is to do a manual fsck on external storage, instead of an auto-check. The reason why is because external storage initializes slower than internal storage, and this can appear to be an I/O interruption to the kernel and fsck.
Disabling of auto-checks can be set in /etc/fstab by changing the last field to 0 for external storage entries.

[chud67]

In case it helps someone: per Red Hat, best practice is to do a manual fsck on external storage, instead of an auto-check. The reason why is because external storage initializes slower than internal storage, and this can appear to be an I/O interruption to the kernel and fsck.
Disabling of auto-checks can be set in /etc/fstab by changing the last field to 0 for external storage entries.

[Johan Guldmyr]

cool =) thanks for coming back about that chud!