xfs
[Top] [All Lists]

Re: xfs on armv5 still with erroneous log in kernel 2.6.35.4

To: Marcus Osdoba <marcus.osdoba@xxxxxxxxxxxxxx>
Subject: Re: xfs on armv5 still with erroneous log in kernel 2.6.35.4
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 9 Sep 2010 16:45:24 +1000
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4C87D793.8000103@xxxxxxxxxxxxxx>
References: <4C835A34.9080008@xxxxxxxxxxxxxx> <20100906005230.GX7362@dastard> <4C845EDE.3010806@xxxxxxxxxxx> <4C8534D0.3050003@xxxxxxxxxxxxxx> <20100907060331.GK705@dastard> <4C86B4E3.5090202@xxxxxxxxxxxxxx> <20100908074357.GS705@dastard> <4C87D793.8000103@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Sep 08, 2010 at 08:36:03PM +0200, Marcus Osdoba wrote:
>  Am 08.09.2010 09:43, schrieb Dave Chinner:
> >mount -t xfs /dev/sda1 /data
> >cp /bin/sh /data
> >sync
> >umount /data
> >xfs_printlog /dev/sda1
> #no ERROR entry visible

Again, can you pleae paste the entire logprint output here?  I'm
asking for _exactly_ what is in your terminal as a result of the
commands you ran. That is, if everything is working correctly, I
would expect you to be pasting in something like this:

# mount /dev/vdb /mnt/scratch
# cp /bin/sh /mnt/scratch
# sync
# umount /mnt/scratch
# xfs_logprint -t /dev/vdb
xfs_logprint:
    data device: 0xfd10
    log device: 0xfd10 daddr: 10485792 length: 20480

    log tail: 6924 head: 6924 state: <CLEAN>

#

If it is different to this, then those differences might
tell me is going wrong. but without the exact commands and output,
I cannot help you....

> # The following command chain trys to reproduce the error
> >mount -t xfs /dev/sda1 /data
> >cp /bin/* /data
> >sync
> Device or resource busy.

This should not be occurring.  What is generating this error? is
there anything in your logs/dmesg, etc that indicates what might be
the cause?  This is the error that we need to understand first...

> My expectations:
> - sync should never be mandatory before  unmounting to keep the FS
> clean (any FS)

It's not. I asked you to run it first to separate writeback from the
unmount process to determine if it was writeback that was having
problems. Clearly, if sync is triggering an error, then the problem
is realted to writeback, and not unmount.

FYI: Without a sync, you should still see a clean log:

# mount /dev/vdb /mnt/scratch
# cp /bin/* /mnt/scratch
# umount /mnt/scratch
# xfs_logprint -t /dev/vdb
xfs_logprint:
    data device: 0xfd10
    log device: 0xfd10 daddr: 10485792 length: 20480

    log tail: 8703 head: 8703 state: <CLEAN>

#

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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