Collecting the file system metadata, and other information, in the event of possible VxFS file system corruption
Article ID: 100027324
Updated On:
Description
Problem
This article contains a procedure for preserving the file system metadata in the event of possible corruption
Solution
| This article is a part of a set on troubleshooting file system corruption. Click here to start at the beginning: https://www.veritas.com/content/support/en_US/article.100009174 |
Table of Contents
1. Introduction
2. Use "script" to preserve the data gathering session
3. Use "fsck -n" to test for possible corruption
4. Use "ls" to collect a list of inodes
5. Gather a "metasave" of the suspect file system
6. Use "dd" to copy the meta data front-end of the corrupted file system
7. Gather a "ncheck" of the suspect file system
8. Use the Data Collector to gather additional logs
9. End the "script" collection process
10. Compress and upload the following items to the evidence server
1. Introduction
(Back to top)
When VxFS file system corruption is suspected, the degree of corruption can be often assessed *before* attempting to run “fsck –y." Gathering a "metasave" of the filesystem, along with other information makes it possible to safely run fsck against a "replay" of the filesystem metadata instead of running it against actual production data.
Script is a native utility that is used to record a "typescript" of everything that is typed within a terminal. In this case, the recorded typescript can be used to verify that the gathering process was performed correctly.
Figure 1 - Using script to record a typescript
Syntax: script vxfs_info.out Example, with typical output: # script vxfs_info.out Script started, file is vxfs_info.outNote: A blank prompt is expected here. The process will continue recording a typescript until the "exit" command is issue. Continue to the next step. |
3. Use "fsck -n" to log the current status of the suspect file system
When using the "-n" argument, fsck will simply report its findings without making any changes.
Warning: Do not use the "-y" switch at this time.
Figure 2 - Using vxfs with the "-n" switch to test for filesystem corruption
| Syntax: /usr/lib/fs/vxfs/fsck -F|t vxfs -n -o full,nolog /dev/vx/rdsk/ Note: Only use the version of fsck that comes with Storage Foundation for VxFS volumes. More information about this can be found here: https://www.veritas.com/content/support/en_US/article.100021267 Example, with typical output: # umount /vol1 # /usr/lib/fs/vxfs/fsck -F vxfs -n -o full,nolog /dev/vx/rdsk/datadg/vol1 >/var/tmp/fsck-n.out |
4. Use "ls" to collect a list of inodes
Figure 3 - Using "ls -aliR" to gather a list of inodes
Syntax: ls -aliR Example, with typical output: Note: If possible, mount the file system in "read-only" mode before performing this step.
# mount -t vxfs -o ro /dev/vx/dsk/datadg/vol1 /vol1 # mount | grep -i vx /dev/vx/dsk/datadg/vol1 on /vol1 type vxfs (ro,largefiles,ioerror=mwdisable)# ls -aliR /vol1 > /var/tmp/ls_all_files.out |
Use one of the provided metasave scripts to create file that contains a copy of the metadata of a volume. The metadata is a data structure that contains attributes about the data within a filesystem, but does not contain the actual data itself.
"How to create a metasave"
Mount the volume and then use "dd" to generate a dump of the first 256 MB of the volume.
Syntax: dd if=/dev/vx/rdsk/ Example, with typical output: # mount -t vxfs /dev/vx/dsk/datadg/vol1 /vol1 # dd if=/dev/vx/rdsk/datadg/vol1 of=/var/tmp/dd_config.dump bs=1024k count=256 & [1] 11333 # 256+0 records in |
7. Use "ncheck" to list of path names corresponding to inode numbers for files of corrupted file system
|
Syntax: /opt/VRTS/bin/ncheck /dev/vx/rdsk/ |
8. Use the Data Collector to gather additional logs
(Back to top)
"Using the SORT Data Collector to gather logs for Storage Foundation Technical Support"
Syntax: exit Example, with typical output: # exit exitNote: The recorded typescript will be saved in the output file that was previously specified.
|
(Back to top)
If the logs were gathered at the request of Technical Support, upload them to the "evidence server" using these steps:
1. The "script" session output file (from Step 2 & 8).
2. The "fsck" output file (from Step 3).
3. The "ls -aliR" output file (from Step 4).
4. The "metasave" output file (from Step 5).
5. The "dd" dump file (from Step 6).
6. The "ncheck" output file (from Step 7).
7. The "Data Collector" output file (from Step 8).
This article contains information about providing data to Technical Support
Issue/Introduction
