[Top] [All Lists]

Re: xfs on armv5 still with erroneous log in kernel

To: Marcus Osdoba <marcus.osdoba@xxxxxxxxxxxxxx>
Subject: Re: xfs on armv5 still with erroneous log in kernel
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 7 Sep 2010 16:03:31 +1000
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4C8534D0.3050003@xxxxxxxxxxxxxx>
References: <4C835A34.9080008@xxxxxxxxxxxxxx> <20100906005230.GX7362@dastard> <4C845EDE.3010806@xxxxxxxxxxx> <4C8534D0.3050003@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Sep 06, 2010 at 08:37:04PM +0200, Marcus Osdoba wrote:
>  Am 06.09.2010 05:24, schrieb Eric Sandeen:
> >
> >I do, and owe their donors some testing; if this is still failing
> >on a kernel with the vipt stuff in place I'll haul them out and
> >do some testing..
> >
> >-Eric
> Hi Eric,
> Thank you both for your ansers.
> I'm using the latest stable kernel The filesystem was
> created on the target device with a cross compiled xfsprogs 3.1.3.
> The systems runs on an armv5te architecture (sheevaplug derivative).
> After creating, mounting and writing some data on it, re-mounting
> was not possible with the above mentioned error. I've found this
> message in the mailinglistarchive and thought the patches were
> integrated into mainline.
> How can I help? What additional information do you need?

can you see if xfs_logprint can parse the log? probably best to
use the "-t" option for transactional output as that should be the
equivalent of log recovery parsing the log.

Further, can you make sure you are mounting a clean filesystem
by running sync a couple of timeѕ before you unmount? If the log is
clean and you are seeing the problem, it will narrow down the
possible causes of the problem. xfs_logprint should tell you if the
log is clean or dirty....


Dave Chinner

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