Sun StorageTek[TM] 5000 Series NAS arrays: Filesystem not mounted, previous mount did not complete

Asset ID:	1-71-1008158.1
Update Date:	2017-02-09
Keywords:

Solution Type Technical Instruction Sure

Solution 1008158.1 : Sun StorageTek[TM] 5000 Series NAS arrays: Filesystem not mounted, previous mount did not complete

Applies to:

Sun Storage 5320 NAS Appliance - Version All Versions and later
Sun Storage 5210 NAS Appliance - Version All Versions and later
Sun Storage 5220 NAS Appliance - Version All Versions and later
Sun Storage 5310 NAS Appliance - Version All Versions and later
Sun Storage 5310 NAS Gateway System - Version All Versions and later
All Platforms

Goal

Description

An array experienced a power loss or crash during the mount operation. The filesystem does not appear in diagnostic email and is inaccessible via NFS/CIFS, underlying raid volume remains up and active.

Solution

Steps to Follow

The most common reason for the mount failure is a power loss or crash during the mount process. This causes a "mount failure" flag to be set on the volume. When the Sun StorEdge[TM] 5x10 NAS Appliance encounters this flag upon boot, it does not mount the volume, and logs the following message:

  I sfs2: /volume - id=4D9721D3, extent 1 of 3, version 2
  I sfs2: /volume - id=4D9721D3, extent 2 of 3, version 2
  I sfs2: /volume - id=4D9721D3, extent 3 of 3, version 2
  I /[2] fruitless bitmap 168 bytes
  I /[1] fruitless bitmap 252 bytes
  I /volume[0] fruitless bitmap 252 bytes
  A /volume not mounted, previous mount did not complete. <----
  A dpmgr: Error sfs2-mount isp1d020,3

In some cases, the bootlogs may not contain the original failure because too much time had passed. All subsequent unsuccessful attempts to mount the volume will log the same error message "previous mount did not complete".

The LunPath Information should show that the device is up and active.

Dasdid 600 isp1d020 has 2 paths, Owner Real 1 Current 1
P1: isp1d020 status(3) UP ACTIVE
P2: isp3d000 status(1) UP

If it is 100 percent certainty that the problem is an interrupted mount attempt, the filesystem will need to be force mounted and fsck'd. fsck can only run if the filesystem is mounted.

CLI command "mount -f /volume"

Check the log again to confirm that the filesystem mounted, and run fsck.

In some cases, the above command may not be successful and may even hang.
In such cases, one can attempt a mount of the filesystem without the journals used by the filesystem.
The filesystem used by the NAS is a journaling filesystem and these journals are used to hold the data before it is committed to the main filesystem. There is a possibility that the filesystem is not getting mounted because of some issues with the journal.

You can reset the journals by using the following command on the volume. This will cause the data that has been written to the journals and not yet committed to the main filesystem to be lost. This would naturally be a small amount of data compared to the rest of the filesystem.

"mount -f -o nojnl,rw /volume"

After which you must run fsck - ensure fsck is run twice

This document contains normalized content and is managed by the the Domain Lead(s) of the respective @ domains.

For more information about the fsck process on the NAS array, refer to:

Document: 1006816.1 Performing and understanding the fsck procedure on the SunStorageTek[TM] 5000 Series NAS arrays to recover from a filesystem crash

Information regarding this process is pulled directly from: http://pts-storage.us.oracle.com/products/SE5210/documents/SE5310_tsg_rev6.pdf

Refer to Section 2.14 File System Issues
and section 2.7.1 Filesystem Check (fsck) Procedure

5310, 5x10, 5210, 5220, 5320, 5320C, 5310C, fsck file system, nas, cifs, nfs, audi, mount, mounted, sfs2, audited
Previously Published As
85455

***Checked for relevance on 20-JAN-2014***

***Checked for relevance on 08-SEP-2015***

***Checked for relevance on 09-FEB-2015***

Attachments

This solution has no attachment