Lustre discuss - Aug 2008 - object to OST inode to MDS inode to filename

Sorry about subject on first try.

I am trying to track logged errors upstream from the error to the
file that may have been affected.

What is the easy(and not so dangerous) way to:

1. derive OST inode from OST object?
OST object modulo 32 for directory on OST
then run debug.ldiskfs(stat) the file(ost object),
after cd into O/0/d$modulo_number,
that displays inode of object on the OST

2. derive MDS inode from OST inode?
use a tool that is nice uses OST inode and gives me the mds inode or
decode using source code the extended attributes
that are in some hex string that is in the output
from the debugfs step above at "fid =" line.

3.derive filename from MDS inode?
run debug.ldiskfs(ncheck) the MDS inode
that displays the filename.

PS; debug.ldiskfs used with -c option to load faster.

-- 
}}}===============>>  LLNL
James E. Harm (Jim); jharm at llnl.gov
System Administrator, ICCD Clusters
(925) 422-4018 Page: 423-7705x57152

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



Jim Harm wrote:
| Sorry about subject on first try.
|
| I am trying to track logged errors upstream from the error to the
| file that may have been affected.
|
| What is the easy(and not so dangerous) way to:
|
| 1. derive OST inode from OST object?
| OST object modulo 32 for directory on OST
| then run debug.ldiskfs(stat) the file(ost object),
| after cd into O/0/d$modulo_number,
| that displays inode of object on the OST

(I will repost my reply to you as well)
Jim,
We have a rudimentary tool that I developed here at LLNL that
does what I think you want here.
You asked for getting an OST inode from an ost object.  All you have
to do is stat the file using debugfs to get at that information.
What I think you want is something a bit more tricky.

We had an incident here where the fsck found some corruption and
moved some OST objects into the lost+found.  One nice thing about
Lustre is that it stores extended attributes about the file with
the inode.

We have a tool here called eadump.ldiskfs that reads and decodes the
extended attribute information for an ost object.  This tells you
what the object id should be for the file as well as what the mds
inode should be as well (This also answers youe #2 below)...=)

EG:
| eadump.ldiskfs -d /dev/sdc -i 105906277
Name: trusted.fid Value: MDSINO: 112108525 GEN: 1401146486 STRIPEIDX: 1 OBJID:
10942568 GROUP: 0


|
| 2. derive MDS inode from OST inode?
| use a tool that is nice uses OST inode and gives me the mds inode or
| decode using source code the extended attributes
| that are in some hex string that is in the output
| from the debugfs step above at "fid =" line.
|
| 3.derive filename from MDS inode?
| run debug.ldiskfs(ncheck) the MDS inode
| that displays the filename.

Using ncheck in debugfs is the only way I know of to get at this information.
This is a SLOW process since it has to rumble through the filesystem for it.
You should also note that this filename may not be the only one pointing to
that inode.

|
| PS; debug.ldiskfs used with -c option to load faster.
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEAREKAAYFAkic0hsACgkQP/62XqEEbMYncACglOkbV3f1DNpvsAcAQW0R1mFK
L+YAnRmLrrtzOUbXgHzEn546wyW4fjj3
=rWjQ
-----END PGP SIGNATURE-----