CentOS 5 File System Read Only Issue

Home » CentOS » CentOS 5 File System Read Only Issue
CentOS 3 Comments

Hello Everyone,

We are using CentOS 5 system for certain application. Those are VM guests running in VMware. There is datastore issue occasionally, causing all file systems becoming read only file systems. So application stop working, and opened files cannot be written either. We cannot even SSH login to the system. Typically we had to power cycle the VM. We are trying to add reliability to the application so that if files cannot be written, application should time out. We are trying to use IO::Select to handle timeout. Per investigation, we found below does not work as expected:

my $s = IO::Select->new( $fh );
if ( $io->can_write( 10 ) {
# print to the file
}

It seems like can_write returns true even we manually made file system read only in our testing case.

Is this something we can accomplish using select system call with timeout value?

Thanks in advance,

– Xinhuan Zheng

3 thoughts on - CentOS 5 File System Read Only Issue

  • Orthogonal consideration:
    I don’t know the version of vSphere you are using and if you are using or not VMware Tools inside your guests. But installing VMware tools in vSphere 4 or higher has the effect to change disk timeout for the guest to 180 seconds, from its default of 30 seconds
    (that I think is the same for RH EL/ CentOS 5,6,7)
    This may or may not help you in case of short time storage problems.

    Eg on a 6.5 infrastructure with an old legacy CentOS 5.9 VM I have VMware Tools: Running, version:8305 (Unsupported older version)
    and inside guest

    # service vmware-tools status vmtoolsd is running
    #

    # find /sys/class/scsi_generic/*/device/timeout -exec grep -H . ‘{}’ \;
    /sys/class/scsi_generic/sg0/device/timeout:180
    /sys/class/scsi_generic/sg1/device/timeout:180
    #

    See also:
    this if you have access to Red Hat Customer Portal (disk scsi timeout and how to set it in RH EL 5):
    https://access.redhat.com/solutions/301963

    Similar considerations for RH EL 6 and 7:
    https://access.redhat.com/solutions/2470541

    This publicly accessible for RHEL 5
    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/task_controlling-scsi-command-timer-onlining-devices.html

    this related to vSphere:
    https://kb.vmware.com/s/article/1009465

    this for APD (All Paths Down) timeout that defaults to 140 seconds for block storage https://kb.vmware.com/s/article/2032934

    HIH, Gianluca

  • That’s not designed to do what you hope. select(2) is a system call intended for use on network socket handles, not file handles. Since socket handles and file handles are compatible on a Unix type system (including CentOS) the call doesn’t fail, but it *cannot* report the information you’re hoping to get.

    I would first try calling the -w operator:

    print_to_file() if -w $fh;

  • First off I would be remiss if I didn’t point out that CentOS 5 has been EOL for years, that said…

    You’re dealing with perl here and so this might be better off asking in a perl list. The -X system of tests as documented with “perldoc -f -X”
    do not by default test actual ability to read and write files, but instead just check the file mode bits as returned by stat(), thus the -w test will not reflect the filesystem being in read-only mode.

    There are two ways to get around this. One is to to use the filetest pragma which changes the behavior of the -X tests to use the access(2)
    system function:
    { use filetest ‘access’;
    print_to_file() if -w $fh;
    }

    The other way is to use POSIX::access() directly (this requires the file name or path):

    use POSIX qw(access W_OK);

    …

    print_to_file() if access($filepath, W_OK);

    Note that there are caveats to either of the above approaches as per documentation. See the following for additional info:

    perldoc -f -X
    perldoc filetest access(2)

    Peter