hank peng wrote:
> 2009/12/1 Eric Sandeen <sandeen@xxxxxxxxxxx>:
>> hank peng wrote:
>>
>>> Today, I encountered a problem:
>>> I use "xfs_repair -L “ on a damaged filesystem and a lot of messages
>> why did you use -L, did it fail to mount & replay the log properly?
>>
> umount, mount, umount and then xfs_repair failed, so I have to use -L.
Failed how? that's a bug. (or, -L did nothing anyway because the log
wasn't dirty after the clean unmount)
>>> output which include "moving disconnected inodes to lost+found ...".
>>> Then I can remount the filesystem successfully and decided to remove
>>> those files in lost+found directory, but it printed the following
>>> message:
>>> root@1234dahua:/mnt/Pool_md1/ss1/lost+found# rm -rf *
>>> rm: cannot stat '710': Structure needs cleaning
>>> rm: cannot stat '728': Structure needs cleaning
>>> rm: cannot stat '729': Structure needs cleaning
>>> rm: cannot stat '730': Structure needs cleaning
>>> rm: cannot stat '731': Structure needs cleaning
>>> rm: cannot stat '732': Structure needs cleaning
>>> rm: cannot stat '733': Structure needs cleaning
>>> rm: cannot stat '734': Structure needs cleaning
>>> rm: cannot stat '735': Structure needs cleaning
>> Look at dmesg to see what's gone wrong....
>>
>
>>> Other directories and files seems normal to access, is it not allowed
>>> to delete files in lost+found directory after repair, then what should
>>> I do?
>> This is indicative of a bug or IO error that caused xfs to shut down.
>>
>> You haven't mentioned which kernel version, architecture, or
>> version of xfsprogs you're using yet ... that may offer some clues.
>>
>
>> I'm guessing an older kernel and userspace on arm? :)
>>
> kernel version is 2.6.23, xfsprogs is 2.9.7, CPU is MPC8548, powerpc arch.
> I am at home now, Maybe I can provide some detailed information tomorrow.
If there's any possibility to test newer kernel & userspace, that'd
be great. Many bugs have been fixed since those versions.
-Eric
>> -Eric
>>
>
>
>
|