Forum Discussion

ARUP_JYOTI_THAK's avatar
ARUP_JYOTI_THAK
Level 4
12 years ago
Solved

corrupted veritas file system

Dear Support

I am facing the below issue whenever running the fsck,please find the below details---

****************************************************************************************************

[10:40am] root@dwse: # /opt/VRTS/bin/fsck -F vxfs /dev/vx/rdsk/storagedg/vardws_vol
UX:vxfs fsck: ERROR: V-3-20005: read of super-block on /dev/vx/rdsk/storagedg/vardws_vol failed: No such device or address
file system check failure, aborting ...
Exit 1
 
Exit 34
[10:43am] root@dwse: # /opt/VRTS/bin/fsck -F vxfs /dev/vx/rdsk/storagedg/varoptbgw_vol
UX:vxfs fsck: ERROR: V-3-20005: read of super-block on /dev/vx/rdsk/storagedg/varoptbgw_vol failed: No such device or address
file system check failure, aborting ...
Exit 1
[10:44am] root@dwse: #
 
*********************************************************************
Due to which volumes cannot be able to mount,kindly suggest what need to do/
 
 
regards....Arup
Basics
business continuity
Managing Backup Devices
Solaris
Storage Foundation
Training
Troubleshooting
  • Daniel_Matheus's avatar
    Daniel_Matheus
    12 years ago

    Maybe the volume or subdisks were disabled due to an intermittent error.

    Next time you should check syslogs, vxprint, vxdisk output and the dmpevents log.

    What can also happen is that you added/removed LUNs which triggered a re-enumeration of the OS devices so that the DMP devices nodes were pointing to the wrong or non existent OS devices

8 Replies

Sort By
  • g_lee's avatar
    g_lee
    Level 6
    12 years ago

    Moved to correct forum (from Storage and Clustering Documentation to Storage Foundation)

    In the meantime, please provide the following output:

    # vxprint -qhtrg storagedg

    # vxdisk -o alldgs list

  • ARUP_JYOTI_THAK's avatar
    ARUP_JYOTI_THAK
    Level 4
    12 years ago

    Hi Everyone

    The issue got resolved,after rebooting the server,what it did during rebooting fsck runs & checks the fs for any error.After checking it make the fs as clean.

     

     

    regards...Arup

  • Marianne's avatar
    Marianne
    Level 6
    12 years ago

    No such device or address 

    This means that the devices were not present at OS level.

    The reboot then detected the disk devices resulting in successful fsck.

  • ARUP_JYOTI_THAK's avatar
    ARUP_JYOTI_THAK
    Level 4
    12 years ago

    No, devices were present in the OS as the concerned DG is showing enabled & also the corresponding volumes from the DG are showing active & enabled in the vxprint output. Still the VXVM fsck was not running & giving the above mentioned error.Finally we have to reboot the server.

  • Daniel_Matheus's avatar
    Daniel_Matheus
    Level 4
    12 years ago

    Maybe the volume or subdisks were disabled due to an intermittent error.

    Next time you should check syslogs, vxprint, vxdisk output and the dmpevents log.

    What can also happen is that you added/removed LUNs which triggered a re-enumeration of the OS devices so that the DMP devices nodes were pointing to the wrong or non existent OS devices

  • Daniel_Matheus's avatar
    Daniel_Matheus
    Level 4
    12 years ago

    Hi Arup,

     

    it's in /etc/vx

     

    Please see belwo link for details:

    http://sfdoccentral.symantec.com/sf/5.1SP1/linux/html/dmp_admin/ch06s04.htm

     

  • Gaurav_S's avatar
    Gaurav_S
    Moderator
    12 years ago

    If the error is saying "no such device or address" that means the volume device itself was not existing in /dev/vx/rdsk/storagedg/  directory.

    One thing I would be interested to know is, whether all the volumes in this DG faced the same error or there were some working (serving I/O) to filesystems were existing ? Any recent deport/import operations happened ?

    If in case, all the volumes had issues, I would also suspect that the DG itself had issues or somehow vxio or vxconfigd was unable to talk to DG leaving it in stale state. This would also trigger a pointer to know if there were any storage issues during the same time (any errors observed in /var/adm/messages file ?)

    If above isn't the case (i.e some volumes were working), then did someone manually deleted the block device files from /dev/vx/rdsk/storagedg/  directory ?

     

    G