xfs
[Top] [All Lists]

Re: XFS umount issue

To: Paul Anderson <pha@xxxxxxxxx>
Subject: Re: XFS umount issue
From: Nuno Subtil <subtil@xxxxxxxxx>
Date: Tue, 24 May 2011 12:10:44 -0700
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=zlL/PDqKPp1NFSFXGq80jMu1CQIXnxJKREmhFwHKdKM=; b=fddKJXdV32+SOxClaomEx9KVunYi2UesjnSt+K+u6EN6fpvddhPY6Yut99JqT4JUvI dnwSHmDyHYvhGz++pqxUOHqb1TWtN85dbs1euJwmsE/kJmzTpLtkZCoQN/azsU1m+9Xq so1JHnnxaQLFpZp+3MKumRFJ6MERBgR9nglMo=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=x6AeytDf6NynxFHo7y3Oqcn5uLwJLVnB0AjTckvaVGDyHGAX/XwyVoZi1UvLEIfinC 62RDmmRSI0WPFIRCdiqVvGibEPm8+Rw6X3E9a0CMkOCYAQ2HhSe7cKlH9kd/xCTPw0v4 5vOh8wk5XX1BnHtPAZNXiPAh+vJereXgBmDDM=
In-reply-to: <BANLkTin26bRHiaCxc15ZwjX__NR3QHaSFA@xxxxxxxxxxxxxx>
References: <BANLkTikNMrFzxJF4a86ZM55r3D=ThPFmOw@xxxxxxxxxxxxxx> <BANLkTin26bRHiaCxc15ZwjX__NR3QHaSFA@xxxxxxxxxxxxxx>
On Tue, May 24, 2011 at 06:33, Paul Anderson <pha@xxxxxxxxx> wrote:
> Hi Nuno - can you elaborate on the ARM hardware?  I noticed that my
> XFS on ARM was mildly unstable, but felt it wasn't XFS code, but
> rather the ARM port of Linux.  My test case is a Seagate Dockstar
> hacked to run Linux.

Mine is a Netgear Stora. The interesting bit is that the stock
firmware runs kernel 2.6.22.18 and uses XFS as well, but I don't know
how stable it was to begin with.

>
> I'll see if I can update to the latest kernel and test this use case
> as well - it would be interesting to see how well it works (I'd like
> to run my Dockstar as a mythtv server - stability was good enough for
> proof of concept, but not longer term use).
>
> Thanks,
>
> Paul
>
> On Mon, May 23, 2011 at 5:39 PM, Nuno Subtil <subtil@xxxxxxxxx> wrote:
>> I have an MD RAID-1 array with two SATA drives, formatted as XFS.
>> Occasionally, doing an umount followed by a mount causes the mount to
>> fail with errors that strongly suggest some sort of filesystem
>> corruption (usually 'bad clientid' with a seemingly arbitrary ID, but
>> occasionally invalid log errors as well).
>>
>> The one thing in common among all these failures is that they require
>> xfs_repair -L to recover from. This has already caused a few
>> lost+found entries (and data loss on recently written files). I
>> originally noticed this bug because of mount failures at boot, but
>> I've managed to repro it reliably with this script:
>>
>> while true; do
>>        mount /store
>>        (cd /store && tar xf test.tar)
>>        umount /store
>>        mount /store
>>        rm -rf /store/test-data
>>        umount /store
>> done
>>
>> test.tar contains around 100 files with various sizes inside
>> test-data/, ranging from a few hundred KB to around 5-6MB. The failure
>> triggers within minutes of starting this loop.
>>
>> I'm not entirely sure that this is XFS-specific, but the same script
>> does run successfully overnight on the same MD array with ext3 on it.
>> This is on an ARM system running kernel 2.6.39.
>>
>> Has something like this been seen before?
>>
>> Thanks,
>> Nuno
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@xxxxxxxxxxx
>> http://oss.sgi.com/mailman/listinfo/xfs
>>
>

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