Virtual TapeServer 6.04.03 Operations and Administration Guide

156 |
mode.
Jun 29 23:45:53 vts001 kernel: e20edb68 e20edba8 f8e887c7 f8e6e68c 00001000
00001000 e9166348 f8fbc000
Jun 29 23:45:53 vts001 kernel: e20edba0 f8e889c0 00000246 00000000 5566af80
e7ef76d8 00000005 00000002
Jun 29 23:45:53 vts001 kernel: e20edbe0 f8ea1786 f8ea8b2f f8ea8a64 000004cb
00000016 e7a73200 00000006
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 of any VTS server in the cluster.
3. Become root:
su -
4. View the file-system table (/etc/fstab) to list the devices:
cat /etc/fstab
5. 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
6. 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