[Lustre-discuss] Lost Files - How to remove from MDT
Miguel Afonso Oliveira
m.a.oliveira at coimbra.lip.pt
Sun Apr 18 10:26:31 PDT 2010
I had a similar problem with one of my filesystems and from my experience until the actual OST, or another one with the same original index, is present, unlink will not work.
It will give the error message an it will keep on showing the reference to the file.
At the time it somehow made sense to me - an erroneous unlink on a missing file would destroy the file metadata. But now I'm not quite sure this ought to be treated as a
feature or as a bug. We can always create an OST with the index of the missing one and unlink. Seems to me a safer option but them it would require better documentation.
All the best,
On Apr 18, 2010, at 6:14 PM, Andreas Dilger wrote:
> On 2010-04-18, at 07:16, Charles Taylor wrote:
>> On Apr 18, 2010, at 9:35 AM, Miguel Afonso Oliveira wrote:
>>> 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
>> unlink /scratch/crn/bwang/NCS/1O5P/1o5p_wat.prmtop
>> unlink: cannot unlink `/scratch/crn/bwang/NCS/1O5P/1o5p_wat.prmtop':
>> Invalid argument
> This surprises me that "unlink" doesn't work, since that is the answer
> I was going to give also. Did you also verify that after this message
> is posted, that the file isn't actually unlinked? I suspect that the
> file name was unlinked, but an error is returned from destroying the
> OST object, but that is fine since the OST is dead and gone anyway.
> What error messages are posted on the console log (dmesg/syslog)?
> Cheers, Andreas
> Andreas Dilger
> Principal Engineer, Lustre Group
> Oracle Corporation Canada Inc.
> Lustre-discuss mailing list
> Lustre-discuss at lists.lustre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1580 bytes
Desc: not available
More information about the lustre-discuss