xfs
[Top] [All Lists]

Re: can xfs_repair guarantee a complete clean filesystem?

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: can xfs_repair guarantee a complete clean filesystem?
From: hank peng <pengxihan@xxxxxxxxx>
Date: Wed, 2 Dec 2009 08:46:20 +0800
Cc: linux-xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oGP8rtMU0N58t4KmrxuYkrCGoThm7kehaDwVL5T0rnY=; b=O4uZqnduue4sbbrLZ4INCy5Rd8v0vnR772QJcVU0sDKNiE0qa1Q4GwTF3V8B3iVlza O9uwk9NCg2Ks33S6pDtS787IZVpfmHOL2kTWbBLwVdiKURJ/ovgd0MVTQWupWw7OdCj7 Oy2ZZX7qeO+yFcOiC6ySWvPYiT5jWtyccPehE=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HWZ21QHhyHMmW7IipwkX5Edx0bcptRwWAkcWLQUuckfPLY5jatGIXUAkJwdRBHP0Gj xVLOeK7ixlBnegPraqLSKJqVmLUHUuBM6duPPFZDCEW86mXeSDzwx4rAD3zKAawe+Jsm LOxmE6wiGnPw61uDZcIVte1YjUCrr7/WXnFFo=
In-reply-to: <4B1539C6.90000@xxxxxxxxxxx>
References: <389deec70911301805j37df7397l1c3ddbbad7e91768@xxxxxxxxxxxxxx> <4B14936F.7040401@xxxxxxxxxxx> <389deec70911302037v19764c2cr7686b353c5e933fa@xxxxxxxxxxxxxx> <4B14B077.5090500@xxxxxxxxxxx> <389deec70911302234v2fc792ddt54bf88f5200500be@xxxxxxxxxxxxxx> <4B152BAD.1000004@xxxxxxxxxxx> <389deec70912010732o72edd3c4q196088a1c01b801e@xxxxxxxxxxxxxx> <4B1539C6.90000@xxxxxxxxxxx>
2009/12/1 Eric Sandeen <sandeen@xxxxxxxxxxx>:
> 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.
>
We did have plan to upgrade kernel to latest 2.6.31.
BTW, Is there some place where I can check those fixed bug list across versions?
> -Eric
>
>>> -Eric
>>>
>>
>>
>>
>
>



-- 
The simplest is not all best but the best is surely the simplest!

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