I have over 52k files in my lost+found of my MGS (not my OSTs). I am not sure what tool I need to use to recover these files. Should i use lfsck or ll_recover_lost_found_objs? TIA
On Apr 04, 2009 09:36 -0400, Mag Gam wrote:> I have over 52k files in my lost+found of my MGS (not my OSTs). I am > not sure what tool I need to use to recover these files. Should i use > lfsck or ll_recover_lost_found_objs?That is only for the OSTs. Unfortunately, there is no easy way to recover them except by e.g. UID/GID and looking at the contents, which is true of local filesystems as well. I''d recommend making a lost+found directory in each user''s home dir and then moving all of their files into their directory (with MDS mounted with -t ldiskfs) and let them sort it out. In Lustre 2.0 and later the MDS inodes will contain an attribute that holds the filename and parent directory ID that will allow recovery in a manner similar to how ll_recover_lost_found_objs does for the OST. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.
I see, so there is no easy way to recover on the MGS. I have a good idea who the user is for these files but the file names are very hard to decypher. They have names like 543434. I am not sure what file that would be part of... On Sat, Apr 4, 2009 at 5:57 PM, Andreas Dilger <adilger at sun.com> wrote:> On Apr 04, 2009 09:36 -0400, Mag Gam wrote: >> I have over 52k files in my lost+found of my MGS (not my OSTs). I am >> not sure what tool I need to use to recover these files. Should i use >> lfsck or ll_recover_lost_found_objs? > > That is only for the OSTs. Unfortunately, there is no easy way to > recover them except by e.g. UID/GID and looking at the contents, > which is true of local filesystems as well. > > I''d recommend making a lost+found directory in each user''s home dir > and then moving all of their files into their directory (with MDS > mounted with -t ldiskfs) and let them sort it out. > > In Lustre 2.0 and later the MDS inodes will contain an attribute that > holds the filename and parent directory ID that will allow recovery in > a manner similar to how ll_recover_lost_found_objs does for the OST. > > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, Inc. > >
On Apr 04, 2009 18:58 -0400, Mag Gam wrote:> I see, so there is no easy way to recover on the MGS. I have a good > idea who the user is for these files but the file names are very hard > to decypher. They have names like 543434. I am not sure what file that > would be part of...The problem at this point is that the directories were corrupted (unfortunately due to bug 18695 I think) and the names of the files are lost. The best that e2fsck can do at this point is to put the files into lost+found with the inode number as the filename.> On Sat, Apr 4, 2009 at 5:57 PM, Andreas Dilger <adilger at sun.com> wrote: > > On Apr 04, 2009 09:36 -0400, Mag Gam wrote: > >> I have over 52k files in my lost+found of my MGS (not my OSTs). I am > >> not sure what tool I need to use to recover these files. Should i use > >> lfsck or ll_recover_lost_found_objs? > > > > That is only for the OSTs. Unfortunately, there is no easy way to > > recover them except by e.g. UID/GID and looking at the contents, > > which is true of local filesystems as well. > > > > I''d recommend making a lost+found directory in each user''s home dir > > and then moving all of their files into their directory (with MDS > > mounted with -t ldiskfs) and let them sort it out. > > > > In Lustre 2.0 and later the MDS inodes will contain an attribute that > > holds the filename and parent directory ID that will allow recovery in > > a manner similar to how ll_recover_lost_found_objs does for the OST.Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.
Thanks for the reply. I already did a e2fsck. The problem is on my clients I see couple of files with "????" in its attributes. I can''t even remove these files to regenerate them. Any idea on how to forcefully remove these files? On Sat, Apr 4, 2009 at 10:30 PM, Andreas Dilger <adilger at sun.com> wrote:> On Apr 04, 2009 18:58 -0400, Mag Gam wrote: >> I see, so there is no easy way to recover on the MGS. I have a good >> idea who the user is for these files but the file names are very hard >> to decypher. They have names like 543434. I am not sure what file that >> would be part of... > > The problem at this point is that the directories were corrupted > (unfortunately due to bug 18695 I think) and the names of the files > are lost. The best that e2fsck can do at this point is to put the > files into lost+found with the inode number as the filename. > >> On Sat, Apr 4, 2009 at 5:57 PM, Andreas Dilger <adilger at sun.com> wrote: >> > On Apr 04, 2009 09:36 -0400, Mag Gam wrote: >> >> I have over 52k files in my lost+found of my MGS (not my OSTs). I am >> >> not sure what tool I need to use to recover these files. Should i use >> >> lfsck or ll_recover_lost_found_objs? >> > >> > That is only for the OSTs. Unfortunately, there is no easy way to >> > recover them except by e.g. UID/GID and looking at the contents, >> > which is true of local filesystems as well. >> > >> > I''d recommend making a lost+found directory in each user''s home dir >> > and then moving all of their files into their directory (with MDS >> > mounted with -t ldiskfs) and let them sort it out. >> > >> > In Lustre 2.0 and later the MDS inodes will contain an attribute that >> > holds the filename and parent directory ID that will allow recovery in >> > a manner similar to how ll_recover_lost_found_objs does for the OST. > > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, Inc. > >
On Apr 04, 2009 22:47 -0400, Mag Gam wrote:> I already did a e2fsck. The problem is on my clients I see couple of > files with "????" in its attributes. I can''t even remove these files > to regenerate them. > > Any idea on how to forcefully remove these files?Probably "chattr -i" to remove the immutable attribute, and use the "unlink" command to delete the files instead of "rm".> On Sat, Apr 4, 2009 at 10:30 PM, Andreas Dilger <adilger at sun.com> wrote: > > On Apr 04, 2009 18:58 -0400, Mag Gam wrote: > >> I see, so there is no easy way to recover on the MGS. I have a good > >> idea who the user is for these files but the file names are very hard > >> to decypher. They have names like 543434. I am not sure what file that > >> would be part of... > > > > The problem at this point is that the directories were corrupted > > (unfortunately due to bug 18695 I think) and the names of the files > > are lost. The best that e2fsck can do at this point is to put the > > files into lost+found with the inode number as the filename. > > > >> On Sat, Apr 4, 2009 at 5:57 PM, Andreas Dilger <adilger at sun.com> wrote: > >> > On Apr 04, 2009 09:36 -0400, Mag Gam wrote: > >> >> I have over 52k files in my lost+found of my MGS (not my OSTs). I am > >> >> not sure what tool I need to use to recover these files. Should i use > >> >> lfsck or ll_recover_lost_found_objs? > >> > > >> > That is only for the OSTs. Unfortunately, there is no easy way to > >> > recover them except by e.g. UID/GID and looking at the contents, > >> > which is true of local filesystems as well. > >> > > >> > I''d recommend making a lost+found directory in each user''s home dir > >> > and then moving all of their files into their directory (with MDS > >> > mounted with -t ldiskfs) and let them sort it out. > >> > > >> > In Lustre 2.0 and later the MDS inodes will contain an attribute that > >> > holds the filename and parent directory ID that will allow recovery in > >> > a manner similar to how ll_recover_lost_found_objs does for the OST. > > > > Cheers, Andreas > > -- > > Andreas Dilger > > Sr. Staff Engineer, Lustre Group > > Sun Microsystems of Canada, Inc. > > > >Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.
I have tried "chattr -i <file>" and then unlink I still get out of bound errors. Any other ideas? TIA On Sun, Apr 5, 2009 at 1:44 PM, Andreas Dilger <adilger at sun.com> wrote:> On Apr 04, 2009 22:47 -0400, Mag Gam wrote: >> I already did a e2fsck. The problem is on my clients I see couple of >> files with "????" in its attributes. I can''t even remove these files >> to regenerate them. >> >> Any idea on how to forcefully remove these files? > > Probably "chattr -i" to remove the immutable attribute, and use the > "unlink" command to delete the files instead of "rm". > >> On Sat, Apr 4, 2009 at 10:30 PM, Andreas Dilger <adilger at sun.com> wrote: >> > On Apr 04, 2009 18:58 -0400, Mag Gam wrote: >> >> I see, so there is no easy way to recover on the MGS. I have a good >> >> idea who the user is for these files but the file names are very hard >> >> to decypher. They have names like 543434. I am not sure what file that >> >> would be part of... >> > >> > The problem at this point is that the directories were corrupted >> > (unfortunately due to bug 18695 I think) and the names of the files >> > are lost. The best that e2fsck can do at this point is to put the >> > files into lost+found with the inode number as the filename. >> > >> >> On Sat, Apr 4, 2009 at 5:57 PM, Andreas Dilger <adilger at sun.com> wrote: >> >> > On Apr 04, 2009 09:36 -0400, Mag Gam wrote: >> >> >> I have over 52k files in my lost+found of my MGS (not my OSTs). I am >> >> >> not sure what tool I need to use to recover these files. Should i use >> >> >> lfsck or ll_recover_lost_found_objs? >> >> > >> >> > That is only for the OSTs. Unfortunately, there is no easy way to >> >> > recover them except by e.g. UID/GID and looking at the contents, >> >> > which is true of local filesystems as well. >> >> > >> >> > I''d recommend making a lost+found directory in each user''s home dir >> >> > and then moving all of their files into their directory (with MDS >> >> > mounted with -t ldiskfs) and let them sort it out. >> >> > >> >> > In Lustre 2.0 and later the MDS inodes will contain an attribute that >> >> > holds the filename and parent directory ID that will allow recovery in >> >> > a manner similar to how ll_recover_lost_found_objs does for the OST. >> > >> > Cheers, Andreas >> > -- >> > Andreas Dilger >> > Sr. Staff Engineer, Lustre Group >> > Sun Microsystems of Canada, Inc. >> > >> > > > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, Inc. > >