The -P option allowed me to complete xfs_repair successfully, but it
also deleted almost everything on the filesystem... A directory that I
could mount -o ro,norecovery before, with tens of GB of data in it, is
now empty... That is really too bad.
Thanks for your help.
On 2/12/10 1:16 PM, Nicolas Stransky wrote:
> Right :)
> I'm using xfsprogs 3.1.0, on Debian Lenny, because 3.1.1 fails to build
> for some reason.
> I've been trying to repair a 1.4TB filesystem for more than a week,
> without success. xfs_repair never completes. I straced the stuck process
> today and got:
> Process 28510 attached - interrupt to quit
> futex(0x429cb58, FUTEX_WAIT_PRIVATE, 2, NULL
> I'm running xfs_repair -P -t5 -m500 /dev/sda1 because the machine only
> has 2GB of RAM and was swapping like crazy. I'll see how it goes with
> the -P option.
> I'm happy to provide xfs_metadump if this still hangs!
> On 2/12/10 12:50 PM, Eric Sandeen wrote:
>> Nicolas Stransky wrote:
>>> I'm running into the same problem exactly, except that it's not 10
>>> minutes, but DAYS.
>>> What is the version that fixes this?
>> hard to say without knowing for sure what version you're using, and
>> what exactly "this" is that you're seeing :)
>> Providing an xfs_metadump of the corrupted fs that hangs repair
>> is also about the best thing you could do for investigation,
>> if you've already determined that the latest release doesn't help.
>>> On 2/12/10 12:02 PM, Richard Hartmann wrote:
>>>> On Fri, Feb 12, 2010 at 17:45, Richard Hartmann
>>>> <richih.mailinglist@xxxxxxxxx> wrote:
>>>>> I thought about that, but I fear that I will flood my terminal off with
>>>>> and/or that I somehow impair xfs_repair while doing so.
>>>> Running it for ten minutes gives me:
>>>> root@grml ~ # strace -p13629
>>>> Process 13629 attached - interrupt to quit
>>>> futex(0xa381b4cc, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...>
>>>> Process 13629 detached
>>>> root@grml ~ #
>> xfs mailing list