BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

Hello Lachlan:

>
> We all start somewhere!
>

Yes. I'll start from this problem :)

>
> It should also be the same architecture too - is it possible you have a
> 32 bit kernel on the 2.6.10 system and a 64 bit kernel on the 2.6.28
> system?  If so then this fix might help
>

The two systems are all 32bit.

Enlightened by your suggestion, I find problem lies in the two systems are
different architecture. One is arm, on is x86. Use 2.6.10 on both system,
XFS created on arm can't mount on x86, vice versa (dump stack at
xlog_recover_process_data).

Use xfs_logprint to inspect log, tool exit with assertion failed:
"item->ri_buf[0].i_len == sizeof(xfs_inode_log_format_t)". Debug the
assertion and find xfs_inode_log_format_t on arm is 56 byte, on x86 is 52
byte. Then find on 2.6.10 xfs_inode_log_format is not packed!! Fix this, fix
the mount failed problem.

Grep the code and find a lot other log/metadata needs pack on 2.6.10. I find
these
 xfs_fid64
 xfs_extent_32_t
 xfs_efi_log_format_32_t
 xfs_efd_log_format_32_t
 xfs_inode_log_format_32_t
 xfs_flock64_32
 compat_xfs_fsop_geom_v1_t
 compat_xfs_inogrp_t
 xfs_dir2_sf_off_t
 xfs_dir2_sf_hdr_t
 xfs_dir2_sf_entry_t

Is there any other log/metadata needs pack on 2.6.10? Any other
problem/caveat I need pay attention to while/besides fix pack bug?

Thanks
Eddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20090728/24a09637/attachment.htm>