Solution if an error is reported when the user unmounts the storage file system on the Linux host side

14

Solution if an error is reported when the user unmounts the storage file system on the Linux host side:
a. A busy message is displayed when the user unmounts the storage file system from the Linux host side.
If a busy message is displayed when the user unmounts the storage file system from the Linux host side, it indicates that a process is using this file. To view the process, perform the following operations:
Enter the following command on the host: fuser -vm /dev/sdc (or /home/hms/data/c).
Format: fuser -vm driver letters (or the file system path)
After checking the process that occupies the file, check the process usage. After the process can be stopped, stop the process and then unmount the file system. To stop a process, run the following command: kill -9 process ID.
If you do not need to check which process is using the file (consequences of stopping processes are not considered), run the following command to stop all processes that use the file:
Enter the following command on the host: fuser -km /dev/sdc (or /home/hms/data/c)
Format: fuser -km drive letters (or the file system path)
Note: Before stopping the process, ensure that stopping the process does not affect the normal running of the host and services. If the preceding operations cannot stop the process, hard reset the host. Before resetting the host, remove the fiber from the host to the storage, or delete the mapping from the storage to the host.
b. A timeout message is displayed when the user unmounts the storage file system from the Linux host side.
A mtab~ file is generated from the default mounting file mtab each time the umount command is being executed. The mtab~ file is a flag file used for mutual exclusion and will be deleted after umount is executed. If the umount operation is not completed, the file will not be deleted. During the execution of umount, it is considered that the previous umount is still running. The mtab~ file will be deleted only after umount is executed. Therefore, the umount operation times out and exits.
Manually delete the mtab~ file and then run umount.
Note: The default mounting directory file of the host may vary with the operating system. Therefore, you need to confirm with the operating system administrator.

Other related questions:
Solution if an error is reported if you install the multipathing software using a disk on a device running the Linux operating system
Solution if an error is reported if you install the multipathing software using a disk on a device running the Linux operating system: Check whether the installation script of the multipathing software /home/linux/Packages contains an uppercase P. If it contains an uppercase P, an error is reported because the directory name of disks cannot contain uppercase letters. In this case, you need to copy the upgrade package from the disk to the local disk.

Method used to identify the cause of a damaged file system in the Linux host
You can locate the cause of a damaged file system as follows: 1. Issue Description How can I identify the cause of a damaged file system in the Linux host? 2. Solution Fault location and rectification If a damaged file system is caused by the operating system, rectify the problem on the operating system side. If a damaged file system is caused by storage disks, rectify the problem on the storage side. Other causes lead to a damaged file system. Solution: a. If the damaged file system is located in interactive personality TV (IPTV), the following information is displayed. Enter the storage directory. Failures such as input out error are displayed or a file system fails to be mounted (you must ensure proper mapping of LUNs and disks added to hosts by the storage system). b. The damaged file system is caused by an operating system failure. Check host logs by going to the /var/log directory and searching for compressed log packages about message (search the latest message log first). Search keyword err in host logs to check whether the following information is displayed (XFS is used as an example). Feb 18 16:19:01 WX-BY-HMU2 kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4534 of file fs/xfs/xfs_bmap.c. Caller 0xffffffff882c4f9c If a internal error is found in the host logs, the error is caused by an operating system failure. Solution: Consult the relevant operating system personnel for troubleshooting. You can refer to maintenance documentation. 3. The damage file system is caused by failures on the storage side. Check host logs by going to the /var/log directory and searching for compressed log packages about message (search the latest message log first). Search keyword err in host logs to check whether the following information is displayed (XFS is used as an example). Dec 7 15:03:00 gdby2-hms01 kernel: end_request: I/O error, dev sdc, sector 2093665280 If an I/O error is found in host logs, the error is caused by a disk fault in the storage system or a link fault between the host and the storage. Solution: You can contact the storage R&D personnel for help. 4. Other Causes The damaged file system is caused by powering on and restarting hosts and storage arrays after abnormal power-off. The damaged file system is caused by transmission medium fault, such as fiber and cable damage, and data transmission link recovery from disconnection. The above scenarios may result in failed I/O delivering on the host and then a file system failure. Solution: Refer to maintenance documentation.

Solution when I/O congestion occurs on the SUSE Linux host
Method used to locate faults when I/O congestion occurs on the SUSE Linux host: 1. Run watch -n 1 cat /sys/class/scsi_host/hostX/host_busy to check whether I/O congestion occurs on the HBA queue. The -n parameter indicates the statistical period in second. 2. Run lsscsi to check HBAs. In step 1, it can be determined whether I/O congestion occurs on the physical HBA or the multipathing virtual HBA (For problems hardly recur, convert the preceding commands to scripts and save the execution result to a local directory for easy check).

Problem and solution when a host of an OceanStor V3 storage system cannot deliver services
Cause: The disk enclosure that encounters a power failure is a sub-group of RAID 10. Data can also be written into other sub-groups. However, if a disk enclosure encounters a power failure, the metadata logs of more than three disks are recorded. Currently, the RAID 1 group has only four disks. Therefore, the logs of a maximum of four disks are recorded. If the logs of extra three logs must be recorded, the logs fail to be recorded and an I/O failure is returned to the host. Solution: Power on the disk enclosure to solve the problem.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top