<p>Hello Lachlan:</p>
<p>><br>> We all start somewhere!<br>></p>
<p>Yes. I'll start from this problem :)</p>
<p>><br>> It should also be the same architecture too - is it possible you have a<br>> 32 bit kernel on the 2.6.10 system and a 64 bit kernel on the 2.6.28<br>> system? If so then this fix might help<br>></p>
<p>The two systems are all 32bit.</p>
<p>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). </p>
<p>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.</p>
<p>Grep the code and find a lot other log/metadata needs pack on 2.6.10. I find these<br> xfs_fid64<br> xfs_extent_32_t<br> xfs_efi_log_format_32_t<br> xfs_efd_log_format_32_t<br> xfs_inode_log_format_32_t<br> xfs_flock64_32<br>
compat_xfs_fsop_geom_v1_t<br> compat_xfs_inogrp_t<br> xfs_dir2_sf_off_t<br> xfs_dir2_sf_hdr_t<br> xfs_dir2_sf_entry_t</p>
<p>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?</p>
<p>Thanks<br>Eddy</p>