Which disk does the file reside

[steven Burgess_2]

Hi all

I have 2 files that for some reason (unknown at the moment) became corrupt at a certain time
last night. I have to investigate the possible reason for this file corruption

The files both reside on the same lvol but in different directories

When checking the lvol it is spread across 2 disks

Unfortunately, the files both c-isam have been rebuilt, no copy made.

How do i know which disk the file resides

I have no errors in syslog - dmesg with regard to the inodes - no full filesystems etc

The disks are part of an array

/dev/dsk/c1t0d1 = 8/4.0.1

/dev/dsk/c1t0d4 = 8/4.0.4


What would be the best way to go about this

Thanks in advance

Steve

[Bill McNAMARA_1]

I have no idea - but lvdisplay -v /dev/vgXY/lvol
whill give you PV extent to lvol mapping.

I have no idea how you can map filesystem inodes/block to that though...

Later,
Bill

[steven Burgess_2]

Hmm

Thanks Bill. OK , what would be the best way to keep a file for further investigation into it's corruption with respect to the inode number ? Would moving it keep the inode number even if I renme it file.bak ?

How would you investigate the reason that a file would become corrupt

A hard one I know

Any ideas appreciated

Thanks

Steve

[Stefan Farrelly]

dd the file in question while running sar -d from another window. You will see which disk it is on as activity will be high while the dd is running, eg;

dd if= of=/dev/null

and from another window sar -d 1 1000

[steven Burgess_2]

Stefan

Good idea, this is an extremely busy server the dd doesn't run long enough

:/sc # dd if=issue.out of=/dev/null bs=1024k count=1000
0+1 records in
0+1 records out

Tell me i'm being a little thick with the dd

Have tried as you mentioned

Have been up all night (on call)

Thanks

Steve

[Stefan Farrelly · Accepted solution]

If the file is so small remove the bs=1024k first and write to a script multiple dd's;

dd if= of=/dev/null
dd if= of=/dev/null
dd if= of=/dev/null
dd if= of=/dev/null
etc..

So at least when you run the script it will continually access the file so now sar -d should show you which disk its on - or else youre going to need to run it when the system isnt so busy to make it easier to spot.

[Trond Haugen]

I once got this note on how to do it:
melanite:/tmp # bdf .
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol6 204800 116254 83247 58% /tmp
melanite:/tmp # grep tmp /etc/fstab
/dev/vg00/lvol6 /tmp vxfs delaylog 0 2
melanite:/tmp # ll -i swlist_jan.orig
2680 -rw-rw-rw- 1 root sys 6265 Nov 13 09:41 swlist_jan.orig
melanite:/tmp # fsdb -F vxfs /dev/vg00/lvol6
> 999 fset
fset header structure at 0x0000000a.0000
fsh_fsindex 999 fsh_volname "UNNAMED"
fsh_version 2 fsh_checksum 0x38f3567e fsh_time Mon Apr 3 17:36:48 2000
fsh_ninode 3616 fsh_nau 1 fsh_old_ilesize 0
fsh_fsextop 0x0 fsh_dflags 0x1 fsh_quota 0 fsh_maxinode 4294967295
fsh_ilistino[65 97] fsh_iauino 64 fsh_lctino 0
fsh_uquotino 69 fsh_gquotino 0
fsh_attr_ninode 0 fsh_attr_nau 0
fsh_attr_ilistino[67 99] fsh_attr_iauino 66 fsh_attr_lctino 68
fsh_features 0 fsh_fsetid 0x0 00000001
clone fsh_next 0x0 00000000 fsh_prev 0x0 00000000
fsh_volid 0x0 00000000 fsh_parentid 0x0 00000000
fsh_clonetime 0x0 00000000 fsh_create 0x0 00000000
fsh_backup 0x0 00000000 fsh_copy 0x0 00000000
fsh_backupid 0x0 00000000 fsh_cloneid 0x0 00000000
fsh_llbackid 0x0 00000000 fsh_llfwdid 0x0 00000000
fsh_alloclim 0x0 00000000 fsh_vislim 0x0 00000000
fsh_states 0x0 fsh_status ""
> 8 b
00000008.0000: a501fcf5
> p S
super-block at 00000008.0000
magic a501fcf5 version 3 ctime Wed Apr 28 19:45:32 1999
log_version 6 logstart 0 logend 0
bsize 1024 size 204800 dsize 204800 ninode 0 nau 0
defiextsize 0 oilbsize 0 immedlen 96 ndaddr 10
aufirst 0 emap 0 imap 0 iextop 0 istart 0
bstart 0 femap 0 fimap 0 fiextop 0 fistart 0 fbstart 0
nindir 2048 aulen 32768 auimlen 0 auemlen 8
auilen 0 aupad 0 aublocks 32768 maxtier 15
inopb 4 inopau 0 ndiripau 0 iaddrlen 8 bshift 10
inoshift 2 bmask fffffc00 boffmask 3ff checksum dc3f4127
free 88546 ifree 1073789800
efree 28 29 9 39 37 53 47 55 40 22 13 4 2 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
flags 0 mod 0 clean 3c time Thu Nov 16 16:12:27 2000
oltext[0] 33 oltext[1] 1282 oltsize 1
iauimlen 1 iausize 4 dinosize 256
dniaddr 3 checksum2 62c
features 0 checksum3 0
> 2680 i
inode structure at 0x0001f6d6.0000
type IFREG mode 100666 nlink 1 uid 0 gid 3 size 6265
atime 974383626 670002 mtime 974104912 470014 ctime 974104912 470014
aflags 0 orgtype 1 eopflags 0 eopdata 0
fixextsize/fsindex 0 rdev/reserve/dotdot/matchino 0
blocks 7 gen 4407 version 0 30719668 iattrino 0 noverlay 0
de: 100623 103879 0 0 0 0 0 0 0 0
des: 1 6 0 0 0 0 0 0 0 0
ie: 0 0 0
ies: 0
The first direct extent is at address 100623. Having a blocksize of 1K, we
should be at on offset of 100623 KB or 98,26 MB into the lvol.
melanite:/tmp # vgdisplay vg00|more
--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
...
PE Size (Mbytes) 4
...
This means that 98,26 MB should be in the 24th extent (counting from 0).
# lvdisplay -v /dev/vg00/lvol6
...
--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c0t4d0 50 50
...
00022 /dev/dsk/c0t4d0 00642 current
00023 /dev/dsk/c0t4d0 00643 current
00024 /dev/dsk/c0t4d0 00644 current
00025 /dev/dsk/c0t4d0 00645 current
..Which means that the file starts at PE 644 on disk /dev/dsk/c0t4d0.

Regards,
Tron

[Dietmar Konermann]

I normally use ncheck in such cases...

e.g. where is /etc/passwd

1) get the inode number of that file:
# ls -i /etc/passwd
1700 /etc/passwd

2) get a list of sectors occupied by it:

# ncheck -F vxfs -S - /dev/vg00/lvol3 | awk '{if ($3==1700)print}'
UNNAMED 999 1700 11144 /etc/passwd
UNNAMED 999 1700 11010 /etc/passwd

So the file uses the sectors 11144 and 11010. A sector is 1KB... so it translates to offsets in KB.

The rest can be done with LVM commands... see above.


Regards...
Dietmar.