xfs
[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfs on armv5 still with erroneous log in kernel 2.6.35.4
From: Marcus Osdoba <marcus.osdoba@xxxxxxxxxxxxxx>
Date: Tue, 07 Sep 2010 23:55:47 +0200
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=2u9AZIMXaxkrQZdOASQNimyZptEzhBXPc1vXkCbf/yo=; b=AqMSfGjUAETADOxkdzcO8E94olr5LSMeBShitYojVaLkiSIjhX69F3P9iH+dJ/TwbX TCCTN2QL3Qhl6EFUcWH1uHW+pMdHDL/K3/UBrGNYL5JfT+uKo466BApyhH9viDIL/nsR Gtam1+Sz5S3XkPGxD11cl8bk2FtVRcPAiVMLs=
Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=GLktbSx/i9lx0RS//pVxjnl9P3/Wk+aWL4WfobbdqMR0nTquLHVQAu90w+whaFk/wn S38IONA4YHC0wN+AMn1svKcwpM2/xLswHkzUD+EtqeoQKt22/0cjJL8JnbRb9dRngu9p rnHBqRYFIcMjEOyhuPxGhz3MWo2hayMOzGipE=
In-reply-to: <20100907060331.GK705@dastard>
References: <4C835A34.9080008@xxxxxxxxxxxxxx> <20100906005230.GX7362@dastard> <4C845EDE.3010806@xxxxxxxxxxx> <4C8534D0.3050003@xxxxxxxxxxxxxx> <20100907060331.GK705@dastard>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
 Am 07.09.2010 08:03, schrieb Dave Chinner:
On Mon, Sep 06, 2010 at 08:37:04PM +0200, Marcus Osdoba wrote:
I'm using the latest stable kernel 2.6.35.4. 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.
>cp something on it
>umount /data
>xfs_logprint /dev/sda1
[...]
============================================================================
cycle: 1        version: 2              lsn: 1,24       tail_lsn: 1,22
length of Log Record: 512       prev offset: 22         num ops: 1
uuid: e590b021-77e1-4b33-96c9-ae2247225127   format: little endian linux
h_size: 32768
----------------------------------------------------------------------------
Oper (0): tid: 5305b794  len: 8  clientid: LOG  flags: UNMOUNT
Unmount filesystem

============================================================================
cycle: 1        version: 2              lsn: 1,26       tail_lsn: 1,26
length of Log Record: 9216      prev offset: 24         num ops: 145
uuid: e590b021-77e1-4b33-96c9-ae2247225127   format: little endian linux
h_size: 32768
**********************************************************************
* ERROR: data block=26                                                *
**********************************************************************
Bad data in 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....
>mount /dev/sda1 /data
>cp something on it
>sync
>umount /data
> xfs_logprint /dev/sda1
[...]
============================================================================
cycle: 1        version: 2              lsn: 1,24       tail_lsn: 1,22
length of Log Record: 512       prev offset: 22         num ops: 1
uuid: e590b021-77e1-4b33-96c9-ae2247225127   format: little endian linux
h_size: 32768
----------------------------------------------------------------------------
Oper (0): tid: 5305b794  len: 8  clientid: LOG  flags: UNMOUNT
Unmount filesystem

============================================================================
xfs_logprint: skipped 4072 cleared blocks in range: 26 - 4097
xfs_logprint: skipped 301142 zeroed blocks in range: 4098 - 305239
xfs_logprint: physical end of log
============================================================================
xfs_logprint: logical end of log
============================================================================
> mount -t xfs /dev/sda1 /data
... mounting without problems.....


Is sync'ing enough for solving this issue? -> Reproduce:
>mount /dev/sda1 /data
>cp something more on it
>sync
>umount /data
>device or resource busy
>sync
>umount /data
> xfs_logprint /dev/sda1
[...]
Oper (239): tid: 8c6285a0  len: 24  clientid: TRANS  flags: none
BUF: #regs: 2 start blkno: 468854881 (0x1bf22861) len: 1 bmap size: 1 flags: 0x0
Oper (240): tid: 8c6285a0  len: 0  clientid: TRANS  flags: none
BUF DATA
----------------------------------------------------------------------------
Oper (241): tid: 0  len: 1  clientid: ERROR  flags: none
xfs_logprint: unknown log operation type (2a01)
**********************************************************************
* ERROR: data block=2                                                 *
**********************************************************************
Bad data in log


*sigh*
That wasn't the solution. Even after sync and unmounting I got an errouneous log.
See attachment for xfs_logprint -t /dev/sda1  output.

So I am forced to wait until xfs really has written all data to disk (when do I know this?) and must I run sync several times? I think umount should wait until sync is complete ... and it should not lead to an errouneous log in my opinion.
Please correct me if I'm wrong or have completly misguided expectations....

The fact is:
After writing much data on the xfs partition with consecutive sync and unmounting, I reproducible gather an erroneous log.

What debug information do you need?

Thanks for your help.

Regards,
Marcus

Attachment: xfs_logprint_t.out
Description: Text document

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