xfs on armv5 still with erroneous log in kernel 2.6.35.4

[Marcus Osdoba]

  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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xfs_logprint_t.out
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20100907/c56c2bc0/attachment.bat>