While I'm thinking about it, that brings up an interesting question. All the OSTs for this file system were originally formatted under 1.6.3. We have since upgraded to 1.8.x. If we reformat the missing OST with the same index under 1.8.2 and add it back into the file system (sans its data) should we expect trouble? We were reluctant to do so since we doubt that this is a tested scenario but perhaps we are being overly paranoid.
Should it be OK to mix OSTs formatted under different versions (1.6 vs 1.8) of Lustre? Seems like it should be OK but you can't test everything and this seems like a bit of an outlier. Regards, Charlie Taylor UF HPC Center On Apr 18, 2010, at 10:47 AM, Miguel Afonso Oliveira wrote: > Hi again, > > Sorry I forgot to mention this only works if the "offending" OST still > exists. If at this time you can no longer re-include the OST where these > files existed then you can still > create a new one with the same index and then you can unlink. > > MAO > On Apr 18, 2010, at 3:16 PM, Charles Taylor wrote: > >> >> On Apr 18, 2010, at 9:35 AM, Miguel Afonso Oliveira wrote: >> >>> Hi, >>> >>> You are going to have to use "unlink" with something like this: >>> >>> for file in lost_files >>> unlink $file >> >> Nope. That's really no different than "rm" and produces the same result... >> >> unlink /scratch/crn/bwang/NCS/1O5P/1o5p_wat.prmtop >> unlink: cannot unlink `/scratch/crn/bwang/NCS/1O5P/1o5p_wat.prmtop': Invalid >> argument >> >> Thanks for the suggestion though, >> >> Charlie Taylor >> UF HPC Center >> >>> >>> Cheers, >>> >>> Miguel Afonso Oliveira >>> >>> P.S.: To build a list of all your lost files you can do a rsync with the >>> dry-run flag. >>> >>> On Apr 18, 2010, at 2:30 PM, Charles Taylor wrote: >>> >>>> We lost an OST several months ago and could not recover it. We decided >>>> to deactivate until we bring some new storage online and can just rebuild >>>> the entire file system. However, now, the MDT still knows about all the >>>> files that were on the lost OST and this results in things like "invalid >>>> argument" and "?--------? ? .." in directory listings. The files >>>> cannot be removed by standard commands. We end up doing something >>>> like.... >>>> >>>> mv Dir to Tmp >>>> cp -r Tmp Dir (this produces lots of 'cp: cannot stat ...' for the >>>> missing files) >>>> mv Tmp /lost+found (this moves all the missing file names more or less out >>>> of the way). >>>> >>>> Is there some way to remove these files from the MDT - as though they >>>> never existed - without reformatting the entire file system? >>>> >>>> Thanks, >>>> >>>> Charlie Taylor >>>> UF HPC Center >>>> >>>> _______________________________________________ >>>> Lustre-discuss mailing list >>>> Lustre-discuss@lists.lustre.org >>>> http://lists.lustre.org/mailman/listinfo/lustre-discuss >>> >> >> _______________________________________________ >> Lustre-discuss mailing list >> Lustre-discuss@lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-discuss > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss _______________________________________________ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
