No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OceanStor 9000 V300R005C00 File System Feature Guide 11

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Troubleshooting

Troubleshooting

This section describes the typical faults and solutions during the use of the NFS protocol enhancement feature.

Installing DFSClient to Overwrite the Existing One on a Mac OS X Client Fails

Symptom

Installing DFSClient to overwrite the existing one on a Mac OS X client fails. The corresponding installation failure message is displayed, as shown in Figure 12-23.
Figure 12-23  Installation failure message

Possible Causes

During the installation process, the kernel fails to be uninstalled. As a result, an installation error is reported.

Fault Diagnosis

Start the Terminal, and run the vim /var/log/install.log command to query the /var/log/install.log file. Log information, as shown in Figure 12-24, is obtained.
Figure 12-24  Log information in install.log

Procedure

  1. On the Terminal, run the reboot command to restart the client.
  2. After the restart, run sudo umount /path to unmount directory, then double-click the installation package of DFSClient. For details, see Installing DFSClient. If the installation failure persists, contact technical support engineers.

A Link on the RHEL Client Is Lost and Services on the Lost Link Stop

After the NFS shared directory is mounted using DFSClient, a link at the mount point is lost, causing system performance deterioration.

Symptom

A link at the mount point of the client is lost and services on the lost link stop. The directory cannot be unmounted. A new link that involves any IP address on the lost link cannot be used for mounting.

Possible Causes

The 6.3 core of the RHEL client has defects. Links established using DFSClient are suspended at the core sunrpc layer. Therefore, services are interrupted and TCP connections are disabled.

Fault Diagnosis

  • Run the netstat |grep nfs command on the client to find link loss. You cannot mount or unmount the directory through the lost link. For details, see Solutions at the official website of Red Hat.
  • On DeviceManager, choose Service Information > NFS, and the number of links displayed decreases.

Procedure

  1. Run cp /usr/local/xnfs/module/sunrpc.ko /lib/modules/2.6.32-279.e16.x86_64/kernel/net/sunrpc to copy the sunrpc.ko file in /usr/local/xnfs/module/ to replace the sunrpc file in /lib/modules/2.6.32-279.e16.x86_64/kernel/net/sunrpc.
  2. Restart the system.

A Kernel Panic Occurs on the RHEL Client

Symptom

A kernel panic means that after detecting a fatal error, the kernel cannot rectify it, causing an service interruption on the RHEL client and the client automatically restarts as a result.

Possible Causes

A Kernel panic is caused by the TCP kernel defect that exists in the versions earlier than kernel-2.6.32-279.8.1.el6.

Fault Diagnosis

After the client abnormally restarts, check whether the following stacking information is logged in the /var/log/messages directory. For details, see RHEL6: Kernel panic in tcp_xmit_retransmit_queue() at official website of Red Hat.

[exception RIP: tcp_xmit_retransmit_queue+128]
        RIP: ffffffff8148c920  RSP: ffff8800282638c0  RFLAGS: 00010202
        RAX: 0000000000000086  RBX: ffff8801041876c0  RCX: 0000000000000003
        RDX: 000000000000002e  RSI: 00000000f1a4b83d  RDI: 0000000000000001
        RBP: ffff880028263910   R8: 0000000000000008   R9: 00000000f1a4b83d
        R10: 0000000000000000  R11: 0000000000000000  R12: 0000000000000000
        R13: 0000000000000000  R14: ffff880104187788  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0000
     #9 [ffff880028263918] tcp_fastretrans_alert at ffffffff81485f37
    #10 [ffff880028263968] tcp_ack at ffffffff81486d93
    #11 [ffff880028263a38] tcp_rcv_established at ffffffff81487d5d
    #12 [ffff880028263a98] tcp_v4_do_rcv at ffffffff8148fd53
    #13 [ffff880028263b38] tcp_v4_rcv at ffffffff814915ce
    #14 [ffff880028263bb8] ip_local_deliver_finish at ffffffff8146f2ed
[exception RIP: tcp_xmit_retransmit_queue+128]
        RIP: ffffffff8147fca0  RSP: ffff880028203850  RFLAGS: 00010246
        RAX: 0000000000000000  RBX: ffff880c0829b000  RCX: 0000000000000002
        RDX: 0000000000000000  RSI: ffff8805f89a4338  RDI: 0000000000000002
        RBP: ffff8800282038a0   R8: 000000000000000d   R9: 000000008b667a73
        R10: 0000000000000002  R11: 000000008b6be2e9  R12: 0000000000000000
        R13: 0000000000000000  R14: ffff880c0829b0c8  R15: ffff8805f89a4300
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     #9 [ffff8800282038a8] tcp_ack at ffffffff81479e03
    #10 [ffff880028203978] tcp_rcv_established at ffffffff8147b138
    #11 [ffff8800282039d8] tcp_v4_do_rcv at ffffffff81483163
    #12 [ffff880028203a78] tcp_v4_rcv at ffffffff81484951
    #13 [ffff880028203af8] ip_local_deliver_finish at ffffffff814626bd
    #14 [ffff880028203b28] ip_local_deliver at ffffffff81462948
    #15 [ffff880028203b58] ip_rcv_finish at ffffffff81461e0d
    #16 [ffff880028203b98] ip_rcv at ffffffff81462395
    #17 [ffff880028203bd8] __netif_receive_skb at ffffffff8142c34b
    #18 [ffff880028203c38] netif_receive_skb at ffffffff8142e408
    #19 [ffff880028203c78] napi_skb_finish at ffffffff8142e510
    #20 [ffff880028203c98] napi_gro_receive at ffffffff81430b99
    #21 [ffff880028203cb8] bnx2x_rx_int at ffffffffa02e25d6 [bnx2x]
    #22 [ffff880028203e18] bnx2x_poll at ffffffffa02e346c [bnx2x]
    #23 [ffff880028203e68] net_rx_action at ffffffff81430cb3
    #24 [ffff880028203ec8] __do_softirq at ffffffff81072191
    #25 [ffff880028203f38] call_softirq at ffffffff8100c24c
    #26 [ffff880028203f50] do_softirq at ffffffff8100de85
    #27 [ffff880028203f70] irq_exit at ffffffff81071f75
    #28 [ffff880028203f80] do_IRQ at ffffffff814f

Procedure

  1. Install a kernel upgrade package and restart the client after the upgrade. For details, see Moderate: kernel security and bug fix update at official website of Red Hat.

    NOTE:

    If you choose to manually upgrade the kernel, you need to obtain an upgrade package that suits the operating system type of the client. To obtain the operating system type of the client, run cat /etc/redhat-release.

    [root@Client2 ~]# cat /etc/redhat-release 
    Red Hat Enterprise Linux Server release 6.3 (Santiago)

  2. Contact technical support engineers to obtain the version of the upgraded kernel and a corresponding DFSClient installation package.
  3. Install DFSClient again. For details, see Installing DFSClient.

When an External DNS Server Is Used, the Linux Client Can Obtain Only One IP Address

Symptom

The client uses an external domain name service (DNS) server, which is configured to the forwarding mode. When a client is mounted using DFSClient, the mount command is executed to query the parameters for the mounting. However, only one buddy address exists and multiple connections cannot be established.

Possible Causes

The client sends a domain name resolution request to the external DNS server. During the first query, the external DNS server forwards the domain name resolution request to InfoEqualizer of OceanStor 9000 and obtains one IP address. During the second time and third time, the external DNS server obtains the preceding IP address from the cache and sends the IP address to the client. The client does not forward the request to InfoEqualizer. Therefore, only one IP address is obtained and multiple connections cannot be established.

Fault Diagnosis

Capture packets on the external DNS server and check whether all requests from the external DNS server are forwarded to OceanStor 9000.

Procedure

    If an external DNS server is used, enter the IP address and InfoEqualizer DNS IP address of the external DNS server in the DNS configuration of the client node. For details, see NFS Protocol Enhancement Feature Guide > Enabling the NFS Protocol Enhancement Feature > Application on the RHEL Client > Configuring the DNS server.

Translation
Download
Updated: 2019-03-30

Document ID: EDOC1000101823

Views: 14178

Downloads: 97

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next