Hi Adam,
You are a life saver. Right before sending this email to the list I
converted the id of one of the known files from hex to decimal and
compared. It didn't match and so I send this email to this list. After
seeing your email I checked it again and it matched with other files. As of
now it looks like my colleague got the wrong inode for the first file.
Now I can generate the inodes for all the files form the database and move
the files into right place on our metadata server with in no time.
Thank you so much. You guys saved us from users' outbursts. Thank you
again.
Best,
Sreedhar.
On Wed, Sep 17, 2014 at 1:50 PM, Adam Brenner <[email protected]> wrote:
> On Wed, Sep 17, 2014 at 10:14 AM, Sreedhar <[email protected]> wrote:
> > Hi,
> >
> > Last week we had a multi disk failure on our lustre metadata server and
> had
> > a major corruption of metadata. Upn e2fsck most of the files were put in
> > lost and found. I got fullpath of all the files from robinhood database.
> But
> > in the lost and found directory all the files are referenced by inode
> number
> > of the parent directory.
> >
> > Now, is there a way we could have inode numbers for all the files from
> the
> > robinhood database? I see id and parent id and I'm thinking it has to do
> > with inode number of an object. Is it possible to generate inode numbers
> > with some sort of algorithm?
> >
> > I would really appreciate it if you could let me know whether it is
> > possible. Our filesystem has been down for a week (e2fsck took a week to
> > finish) and now we are trying to recover some important files and it is
> > becoming pretty hard to match the directories with inode numbers in lost
> and
> > found.
> >
> > I really appreciate any help.
> >
> > Thanks,
> > Sreedhar.
> > New York University.
>
> For a Lustre 2.x filesystem, id is the lustre fid, returned by "lfs
> path2fid" (without the braces).
> e.g.
> > lfs path2fid /mnt/lustre/dir/test
> [0x280000400:0x83:0x0]
> > lfs fid2path /mnt/lustre 0x280000400:0x83:0x0
> /mnt/lustre/dir/test
>
> For other filesystems: id consists of <fs_key>:<inode_number>
> fs_key is specified in robinhood global configuration as fsname, fsid or
> devid.
> fs_key in DB is respectively:
> - a hash of fsname (as shown by mount)
> - fsid (as returned by statfs)
> - device id (as show by stat)
>
> I do not know enough about the lustre internals if fid is the inode
> that is seen by stat or what is shown in the lost+found directory.
>
> Best of luck,
> -Adam
>
> --
> Adam Brenner
> Computer Science, Undergraduate Student
> Donald Bren School of Information and Computer Sciences
> University of California, Irvine
> www.ics.uci.edu/~aebrenne/
> [email protected]
>
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
robinhood-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/robinhood-support
