Error Message

/etc/vx/bin/vxresize -g oracle -F vxfs backup01 +171788288 oracle06 & [1] 15877

[root@gxs-prod-clus1101 ] UX:vxfs fsadm: ERROR: V-3-25280: write failure at devid/blknum 0/402564094 :

Bad file number VxVM vxresize ERROR V-5-1-7514 Problem running fsadm command for volume backup01, in diskgroup oracle  

The /var/adm/messages file showed vxdmp and vxio errors:

Jan 10 16:54:35 gxs-prod-clus1101 vxdmp: [ID 443116 kern.notice] NOTICE: VxVM vxdmp V-5-0-0 i/o error occurred (errno=0x5) on dmpnode 258/0x2

Jan 10 16:54:35 gxs-prod-clus1101 vxio: [ID 917197 kern.warning] WARNING: VxVM vxio V-5-0-1266 Subdisk oracle06-01 block 796739582: Uncorrectable write error

The OS does not recognize the correct size of the resized lun.  Prtvtoc output of the disk still shows the old size.  But Volume Manager already sees the new lun size (as vxdisk resize was ran already).  Thus, when resizing volume, we got the error that we cannot write to non-existent block.  Note that there were also SCSI errors (write, retryable, unit attention) logged in server prior to the resize.

[root@gxs-prod-clus1101 ] prtvtoc /dev/rdsk/c3t20240080E518CBFEd8s2
* /dev/rdsk/c3t20240080E518CBFEd8s2 partition map
*
* Dimensions:
*     512 bytes/sector
*    3012 sectors/track
*      16 tracks/cylinder
*   48192 sectors/cylinder
*   13054 cylinders
*   13052 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       2      5    01          0 629001984 629001983
       7     15    01          0 629001984 629001983
       8      1    01          0     48192     48191

Customer tried to run devfsadm -Cv and cfgadm -al but this did not change the lun size.  Customer realized that they did not perform a reconfigure reboot earlier, just a reboot. Customer then reboot reconfigured the servers by running "reboot -- -r".  This resolved the issue. 

The new lun size was evident in format and prtvtoc after reboot.  The customer was then able to successfully resize the volume/file system using the same command.

Applies To

SFHA 5.1SP1, Solaris 10 x86, 2-node cluster, SCSI3 I/O fencing enabled, Sun 6180 array, Oracle database