[Top] [All Lists]

Re: XFS umount issue

To: Nuno Subtil <subtil@xxxxxxxxx>
Subject: Re: XFS umount issue
From: Paul Anderson <pha@xxxxxxxxx>
Date: Tue, 24 May 2011 09:33:27 -0400
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:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4ZgJbdPZ27Nt4/ZUaXWw0vf837p6GcOS+m82d0ZfOl8=; b=G3zvOtMLbwjro9mCTLyibBZqEh/HoLunSwM/q4QzWMjvkUtW49GpZx5Zqtx07sxSoC amcvgeOx4D8o/CmyDmwXGZC6IBjEFRSE7SM26Ay5iHtvJgEeBeg6BiXd5LtRNYyNi2TI xPK0Vi8P1S7t4GBgQZdJJndc9wKOF3w1xFBRg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Tm1bhy70002d3U2MtIiA/6By2iVs9XUcSxgislRiH0/KfDJ+lx14upM/d88hBgcTFT I5pDjfANGSUdEdcJhbg4rdlVn0Wl0HMKbcPq57lJU2klCagp4dgkUHTnOWE9lTcYQ87G oBlLhPNU0wO4V2GKdE7b4wXK16EqRKhZcgsjE=
In-reply-to: <BANLkTikNMrFzxJF4a86ZM55r3D=ThPFmOw@xxxxxxxxxxxxxx>
References: <BANLkTikNMrFzxJF4a86ZM55r3D=ThPFmOw@xxxxxxxxxxxxxx>
Sender: powool@xxxxxxxxx
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.

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).



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>