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

[Marcus Osdoba <marcus.osdoba@googlemail.com>]

  Am 08.09.2010 09:43, schrieb Dave Chinner:
>
> FWIW, please copy the exact commands and errors from your terminal -
> paraphrasing them like this does not help me underѕtand exactly what
> is happening...
Hi Dave,

I'm very sorry for annoying you. Please excuse this.

You asked me to copy the exact commands from the terminal. I did that 
despite the fact, that I replaced "cp /bin/* /data" with "cp something 
on it". All other commands are 100% the same in exactly the given order 
in the former mail.
Furthermore you asked me to give the output of xfs_printlog with and 
without option -t. I gave that output in the last mail, too.

Please take my apologies and note the workflow I have tested:

 >mount -t xfs /dev/sda1 /data
 >cp /bin/sh /data
 >sync
 >umount /data
 >xfs_printlog /dev/sda1
#no ERROR entry visible
 >mount -t xfs /dev/sda1 /data
#re mounting works fine, no problems!,
#so I thought running a sync before the umount would solve my erroneous 
log problem on ARM devices

# The following command chain trys to reproduce the error
 >mount -t xfs /dev/sda1 /data
 >cp /bin/* /data
 >sync
Device or resource busy.
 >sync
 >umount /data
 >xfs_printlog /dev/sda1
#includes an ERROR entry at the end, see last mail

The output of dmesg after trying to mount a partition on which I wrote 
some files before,
I gave in the very first mail:
"
SGI XFS with ACLs, security attributes, large block/inode numbers, no 
debug enabled
SGI XFS Quota Management subsystem
XFS mounting filesystem sda1
Starting XFS recovery on filesystem: sda1 (logdev: internal)
XFS: xlog_recover_process_data: bad clientid
XFS: log mount/recovery failed: error 5
XFS: log mount failed
"

My expectations:
- sync should never be mandatory before  unmounting to keep the FS clean 
(any FS)
- umount should never break the log of the FS

Facts:
Mounting the XFS-Parttition, writing some data on it and unmounting 
results in an erroneous log which forces a xfs_repair -L on the next mount.
(This I do not expect either...)

I do not know which debug procedures are useful and would give you some 
useful output. Sorry about this.

After summing up the content I gave in the mailchain, please let me 
know, if solving this issue has any chance of success.

Thanks and kind regards,
Marcus

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs