Virtual TapeServer 6.04.02 Operations and Administration Guide

ManualsBrandsHP ManualsServerHP NonStop G-Series

151

152

153

154

155

156

157

158

159

160

150 | Maintaining GFS for VTS

Jun 29 23:45:53 vts001 kernel: Call Trace: [<c010cc7a>] show_stack [kernel] 0x6a 

Jun 29 23:45:53 vts001 kernel: [<c010cca2>] dump_stack [kernel] 0x12 

Jun 29 23:45:53 vts001 kernel: [<f8e887c7>] gfs_asserti [gfs] 0x27 

Jun 29 23:45:53 vts001 kernel: [<f8ea1786>] blkalloc_internal [gfs] 0x116 

Jun 29 23:45:53 vts001 kernel: [<f8ea1bfe>] gfs_blkalloc [gfs] 0x7e 

Jun 29 23:45:53 vts001 kernel: [<f8e7cec2>] get_datablock [gfs] 0xf2 

Jun 29 23:45:53 vts001 kernel: [<f8e76abb>] get_block [gfs] 0xab 

Jun 29 23:45:53 vts001 kernel: [<c0161b4f>] __block_prepare_write [kernel] 0x17f 

Jun 29 23:45:53 vts001 kernel: [<c0162456>] block_prepare_write [kernel] 0x36 

Jun 29 23:45:53 vts001 kernel: [<f8e77160>] gfs_prepare_write [gfs] 0x130 

Jun 29 23:45:53 vts001 kernel: [<c01472e1>] do_generic_file_write [kernel] 0x1c1 

Jun 29 23:45:53 vts001 kernel: [<f8e7179b>] do_do_write [gfs] 0x28b 

Jun 29 23:45:53 vts001 kernel: [<f8e71b6a>] do_write [gfs] 0x15a 

Jun 29 23:45:53 vts001 kernel: [<f8e6fe06>] gfs_walk_vma [gfs] 0x106 

Jun 29 23:45:53 vts001 kernel: [<f8e71c3c>] gfs_write [gfs] 0x8c 

Jun 29 23:45:53 vts001 kernel: 

Jun 29 23:45:53 vts001 kernel: Kernel panic: GFS: Assertion failed on line 1227

of file rgrp.c



Jun 29 23:45:53 vts001 kernel: GFS: assertion: "x <= length" 

Jun 29 23:45:53 vts001 kernel: GFS: time = 1183153553 

Jun 29 23:45:53 vts001 kernel: GFS: fsid=VTSC:VAULT10.3: RG = 191406391 

Jun 29 23:45:53 vts001 kernel: 

Jun 30 01:21:46 vts001 syslogd 1.4.1: restart.

The following procedure checks the file system and attempts to repair file issues found. This

could take many hours to run depending on file system size. For example, a file-system check

of a GFS partition that is 1TB in size may take eight to twelve hours.

To check and repair the file system

1. Migrate the data on the vault to tape, which creates a backup of the data.

2. Log in to the operating system as root on any VTS server in the cluster.

3. View the file-system table (/etc/fstab) to list the devices:

cat /etc/fstab

4. Unmount the VAULT file system on all VTS systems in the cluster by issuing the

following command. If the VAULT is not unmounted, the file system may be damaged and

data loss could occur.

umount /VAULT

5. Run the file system check by entering the following command:

gfs_fsck -y /device

The -y option answers “yes” to all of the gfs_fsck questions and automatically attempts to

repair any damaged files. Results from the file system check and repairs are displayed on

the screen. If the attempted file repair is unsuccessful, the file is moved to a lost+found

directory in the file system. If this occurs and the data in the file is needed, contact your

VTS support personnel for additional recovery steps.

Repeat this step for each device that needs repair.

6. Mount the file system by entering the following:

mount /VAULT