Troubleshooting client access to data

Use the information in this topic to troubleshoot problems that you are having with client access to data.

Problem

A client cannot access or update user data.

Investigation

If a client cannot create a new file
Perform the following steps until the problem is resolved:
  1. Verify that the master metadata server is online.
  2. Verify that the client has connectivity to the master metadata server.
    • From the client, attempt to ping or establish an SSH session with the metadata server.
    • From the Administrative command-line interface, run the lsclient command to see a list of all clients currently being served by the metadata servers in the cluster.

      sfscli> lsclient

  3. Use the ls -l command to list the directory in which the file is to be created to verify that the entire path is correct and accessible.
  4. Verify that you are logged into the client with a user name that has authorization to write files to directories.
    • From an AIX® client, use the id command.
    • From a Windows® client, right-click the directory. Then click PropertiesSecurity.
  5. Verify that your user name has the authorization to write files in the specific directory.
    Note: If you are logged into an AIX client as root or a Windows client as Administrator, make sure that you are running on a privileged client.
  6. Check the quota of the fileset in which the parent directory resides to ensure that there is sufficient space to accommodate the new file and that the fileset is attached.
    1. Access the master metadata server through either the SAN File System console or the Administrative command-line interface.
    2. List the filesets to view the server to which the fileset is attached, the quota percentage and type, the attach point, and the directory.
      • From the Administrative command-line interface, run the sfscli lsfileset -l command.
      • From the SAN File System, click Manage FilingFilesets.
  7. Make sure that the storage pool in which the file will be stored has sufficient space to store the file.
  8. Verify that the client can access the storage device.
    • Use the datapath query command to ensure that the operating system can access the storage device.
    • On an AIX client, you can use the stfsdisk command to determine which disks can be seen. Then you can use the lsvol -l command to correlate the disk back to the device.
If a client cannot access an existing file
Perform the following steps until the problem is resolved:
  1. Verify that your user name has the authorization to read files and that it has authorization to read the specific file.
  2. Verify that the client can access the storage device.
    • Use the datapath query command to ensure that the operating system can access the storage device.
    • On an AIX client, you can use the stfsdisk command to determine which disks can be seen. Then you can use the lsvol -l command to correlate the disk back to the device.
  3. Suspect a problem with corrupt SAN File System metadata.
If a client cannot update an existing file
Perform the following steps until the problem is resolved:
  1. Verify that your user name has the authorization to write to the specific file.
  2. Verify that the client can access the storage device.
    • Use the datapath query command to ensure that the operating system can access the storage device.
    • On an AIX client, you can use the stfsdisk command to determine which disks can be seen. Then you can use the lsvol -l command to correlate the disk back to the device.
  3. Suspect a problem with corrupt SAN File System metadata.
If a client cannot access any data
Perform the following steps until the problem is resolved:
  1. Verify that the client can access the cluster.
    From the client, attempt to sign on to the SAN File System console. If you cannot, suspect one of the following:
    • One or more metadata servers in the cluster are down. See Troubleshooting the cluster.
      Note: The administrative agent will automatically attempt to restart a metadata server if it goes down for any reason. Therefore, if you cannot access a metadata server, you might want to wait a few minutes and try again just to ensure that it is not in the process of restarting.
    • There is an IP network problem between the client and the cluster. See Isolating problems with the SAN File System.
  2. View the system logs and look for any errors that may indicate I/O errors. Attempt to resolve all of these errors.
    • From a client running Windows, you can use the Event Viewer to view the Event Log.
    • From a client running AIX, you can view logging and tracing output, assuming it was previously enabled with the syslog facility.
  3. From the Administrative command-line interface on the master metadata server, run the lslun command to verify that the LUNs are available.
    If the disks are not available, you can rediscover all disks by running the following commands from a metadata server:
    1. Run stopserver from the Administrative command-line interface to stop the SAN File System.
    2. Run rmmod qla2300.
    3. Run insmod qla2300 .
    4. Run /etc/rc.d/init.d/sanfs start to start the SAN File System.
    5. Run startserver from the Administrative command-line interface to start the metadata server.
  4. Verify that the client can access the storage device:
    • Use the datapath query device command to ensure that the operating system can access the storage device.
    • On a client running AIX, use the stfsdisk command to determine which disks can be seen. Then, from the Administrative command-line interface, you can use the lsvol -l command to correlate the disk back to the device.

    To rediscover all disks from a client running AIX, run the client command stfsdisk -discover.

    The disks should automatically be rediscovered on a client running Windows. However, it they are not:
    1. Right-click My Computer.
    2. Select Manage.
    3. Select Storage\Disk Management.
    4. From the Action menu, select Rescan Disks.
  5. Verify that none of the metadata servers in the cluster has recently terminated abnormally. If there was an abnormal termination of a metadata server, you may begin to see errors on the clients even after problems with the failed metadata server have been resolved. If you begin seeing these types of problems, you will need to restart clients:
    • On clients running AIX:
      1. Run rmstclient to unmount the global namespace, remove the virtual client, and unload the file-system driver.
      2. Run setupclient to load the file-system driver, create the virtual client, and mount the global namespace.
    • On clients running Windows, reboot the system.
  6. If the client cannot access user data, suspect the SAN route from the client. See Isolating problems with the SAN File System.
  7. Suspect a problem with corrupt SAN File System metadata.
If a client running Windows receives delayed write failure errors
A delayed write failure error may appear as a message box on the client desktop or in the Event Log. This message indicates that there has been an error writing data from the local file system cache to a storage device. Perform these steps until the problem is resolved:
  1. The message will include the name of the file where the error occurred. Note the name of this file, as the data it contains may have been corrupted and the application using this file may encounter problems using this file's data.
  2. If the file is not part of the SAN File System, refer to your system documentation for resolving file system errors.
  3. If the file is part of the SAN File System:
    1. View the Event Log and resolve any errors that may be related to this problem.
    2. Suspect a communications problem either with the SAN or between the client and the metadata server.

Parent topic: Troubleshooting a SAN File System client

Related reference
lsclient
Isolating problems with the SAN File System
AIX client logging and tracing
Windows 2000 client logging and tracing

Related information
Troubleshooting the local network

Terms of use | Feedback
(C) Copyright IBM Corporation 2003, 2004. All Rights Reserved.