Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao <eddy.y.zhao@xxxxxxxxx>]

Hello Eric:

>
> Well, the fact that you have 2 arches would have been highly relevant in
> your first email.  ;)  Is this the old abi or the new?  Guessing old,
> based on the alignment issues.
>

ARM compiler is producing eabi. The problem lies in: "long long" on arm is 8 bytes aligned, on x86 is 4 bytes aligned. So 4 more bytes are padded before xfs_inode_log_format::ilf_ino on arm.

>
> Well, packing structures like mad is not a great solution[1] - it needs
> to be done carefully & judiciously.  We don't want to pack structures
> that are already aligned on most arches, because this will cause
> performance issues.
>

Interesting. Nice tip.

>
> But I see above you've found a few that were, for various reasons.  Note
> that the dir2 types above use a funky "__arch_pack" to conditionally
> pack only on arm old abi:
>

Get it. Thanks for the reminder.

>
> To be honest, I am not certain that this is "worth fixing" - we already
> have the requirement that log replay can only be done on an architecture
> of the same endianness, and a further requirement that it can only be
> done on architectures with similar alignment rules doesn't seem so bad.
>

Where is the official description of such requirment? The requirment is not obvious to new XFS users, and they should be warned :)

Why is such requirment? For backward compatibility?

I think the requirment is bad. It inhibit user from exchanging data freely between systems, which is an obvious requirment for file system design.

>
> The problem is, if you go off and "fix" this on arm now, you'll find
> that logs created under older arm kernels can't be replayed on newer arm
> kernels and vice versa...
>

Compared with the above restriction("requirment"), we can afford this :)

Do I miss any other log/metadata needs pack on 2.6.10?

Thanks
Eddy