xfs
[Top] [All Lists]

Re: can xfs_repair guarantee a complete clean filesystem?

To: hank peng <pengxihan@xxxxxxxxx>
Subject: Re: can xfs_repair guarantee a complete clean filesystem?
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Tue, 01 Dec 2009 09:44:06 -0600
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <389deec70912010732o72edd3c4q196088a1c01b801e@xxxxxxxxxxxxxx>
References: <389deec70911301805j37df7397l1c3ddbbad7e91768@xxxxxxxxxxxxxx> <4B14936F.7040401@xxxxxxxxxxx> <389deec70911302037v19764c2cr7686b353c5e933fa@xxxxxxxxxxxxxx> <4B14B077.5090500@xxxxxxxxxxx> <389deec70911302234v2fc792ddt54bf88f5200500be@xxxxxxxxxxxxxx> <4B152BAD.1000004@xxxxxxxxxxx> <389deec70912010732o72edd3c4q196088a1c01b801e@xxxxxxxxxxxxxx>
User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
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
>>
> 
> 
> 

<Prev in Thread] Current Thread [Next in Thread>