Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Lachlan McIlroy]

----- "Eddy Zhao" <eddy.y.zhao@gmail.com> wrote:

> >
> > I don't recommend you pull the usb disk out while the filesystem is
> still
> > mounted (if you can avoid it).
> >
> 
> Doing that to emulate power loss scenario our device might experience.
> 
> >
> > I would start by looking through the change history for
> fs/xfs/xfs_log_recover.c
> > and paying particular attention to anything to do with inode
> transactions.
> >
> 
> Not quite familiar with XFS code :(
We all start somewhere!

> 
> >
> > Or try some intermediate kernels and see if you can narrow the fix
> down to a set of
> > changes.
> >
> 
> I'll try to bisect (It will take some time...)
> 
> >
> > # mount /dev/sda1 /mnt/
> > UDF-fs: No VRS found
> > XFS mounting filesystem sda1
> > Starting XFS recovery on filesystem: sda1 (dev: sda1)
> > Filesystem "sda1": xfs_inode_recover: Bad inode magic number, dino
> ptr
> > = 0xc8266700, dino bp = 0xc8281b40, ino = 0
> 
> Because XFS log is OK to 2.6.28 system, which means the log is correct
> in itself.
> Would it be easy for you to debug the problem by compare 2.6.10 log
> recovery code fail point and the corresponding 2.6.28 log record?
Easy?  Not exactly.  Diff'ing 2.6.10 version of fs/xfs/xfs_log_recover.c
with mainline shows over 300 differences.  If you really want to be able
to replay the log on a different system it really has to be running the
same version of XFS for there to be any chance of it working properly.

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

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6d192a9b82212abf1e0e89da6e3a952afba7e4d6

I think it went into 2.6.18.

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

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1500 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eric Sandeen]

Eddy Zhao wrote:
> 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).

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.

> 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?

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.

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:

/* ARM old ABI has some weird alignment/padding */
#if defined(__arm__) && !defined(__ARM_EABI__)
#define __arch_pack __attribute__((packed))
#else
#define __arch_pack
#endif

When I looked around for structure size mismatches on arm old abi, I was
only looking at on-disk structures for which were big-endian.  Because
the log is native-endian, I did not think to check the log structures.

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.
 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...

-Eric

[1]
http://digitalvampire.org/blog/index.php/2006/07/31/why-you-shouldnt-use-__attribute__packed/

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

[-- Attachment #1.1: Type: text/plain, Size: 1819 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2193 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eric Sandeen]

Eddy Zhao wrote:
> 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.

A tool that can be very helpful here is "pahole" found in the dwarves
package:

# pahole -C xfs_inode_log_format xfs-arm-eabi.ko
struct xfs_inode_log_format {
	__uint16_t                 ilf_type;          /*     0     2 */
	__uint16_t                 ilf_size;          /*     2     2 */
	__uint32_t                 ilf_fields;        /*     4     4 */
	__uint16_t                 ilf_asize;         /*     8     2 */
	__uint16_t                 ilf_dsize;         /*    10     2 */

	/* XXX 4 bytes hole, try to pack */

	__uint64_t                 ilf_ino;           /*    16     8 */
	union {
		__uint32_t         ilfu_rdev;         /*           4 */
		uuid_t             ilfu_uuid;         /*          16 */
	} ilf_u;                                      /*    24    16 */
	__int64_t                  ilf_blkno;         /*    40     8 */
	__int32_t                  ilf_len;           /*    48     4 */
	__int32_t                  ilf_boffset;       /*    52     4 */

	/* size: 56, cachelines: 1, members: 10 */
	/* sum members: 52, holes: 1, sum holes: 4 */
	/* last cacheline: 56 bytes */
};

That was for an arm eabi xfs.ko from 2.6.25.  Don't worry about the "try
to pack" message; as long as holes match everywhere it's ok ;)

...


>> 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 :)

For the endian requirement ... not sure where it's doc'd to be honest.
if you don't find it in Documentation/filesystems/xfs.txt feel free to
send a patch ;)

> Why is such requirment? For backward compatibility?

The xfs log was done native-endian for performance reasons, I think.

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

No, it just means that you have to cleanly unmount on one filesystem
before you try to mount it on another different system.

>> 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?

I can't really speak to 2.6.10, I don't want to go back that far ;)  I'm
afraid  you're on your own there.

So just to be clear, on 2.6.28, arm eabi logs replay fine on x86_64?

-Eric

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

[-- Attachment #1.1: Type: text/plain, Size: 921 bytes --]

Hello Eric:

>
> A tool that can be very helpful here is "pahole" found in the dwarves
> package:
>

Nice tool.

>
> So just to be clear, on 2.6.28, arm eabi logs replay fine on x86_64?
>

I don't have x86_64 machine at hand. Replay arm eabi log on ia32 machine
"seems" success (mount "successfully" returns). Actually I guess that's
because 2.6.28 XFS running on ia32 misinterprets unpacked
xfs_inode_log_format produced by arm as xfs_inode_log_format_64. And there
must be something silently goes wrong on disk after replaying the log.
During fixing the problem, I find it is difficult to change the code to
commit packed log item (restricted by xfs_log_iovec_t mechanism). If we
could somehow change this piece of code to use packed structure. The
endianess problem could be solved by add an byte-swap option to xfs_repair
(like e2fsck "-s"). Then we solve the xfs-log-cant-migrate-between-archs
problem.

Thanks
Eddy

[-- Attachment #1.2: Type: text/html, Size: 1109 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

[-- Attachment #1.1: Type: text/plain, Size: 155 bytes --]

>
>  I find it is difficult to change the code to commit packed log item
(restricted by xfs_log_iovec_t mechanism).
>

Forget this. I didn't get it right.

[-- Attachment #1.2: Type: text/html, Size: 230 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

>
> And there must be something silently goes wrong on disk after replaying
the log.
>

Forget this. Nothing on disk will goes wrong even under the
misinterpretation.

[-- Attachment #2: Type: text/html, Size: 237 bytes --]

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

[-- Attachment #1.1: Type: text/plain, Size: 599 bytes --]

>
> Replay arm eabi log on ia32 machine "seems" success (mount "successfully"
returns). Actually I guess that's because 2.6.28 XFS running on ia32
misinterprets unpacked xfs_inode_log_format produced by arm as
xfs_inode_log_format_64. And there must be something silently goes wrong on
disk after replaying the log.
>

Forget this. There's no misinterpretation. Should be

"Replay arm eabi log on ia32 machine success (mount successfully returns).
2.6.28 XFS running on ia32 interprets unpacked xfs_inode_log_format produced
by arm as xfs_inode_log_format_64"

Sorry for patch myself repeatedly : )

[-- Attachment #1.2: Type: text/html, Size: 750 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eric Sandeen]

Eddy Zhao wrote:

...

> During fixing the problem, I find it is difficult to change the code to
> commit packed log item (restricted by xfs_log_iovec_t mechanism). If we
> could somehow change this piece of code to use packed structure. The
> endianess problem could be solved by add an byte-swap option to
> xfs_repair (like e2fsck "-s"). Then we solve the
> xfs-log-cant-migrate-between-archs problem.

Well, to be honest, the restriction of a clean log when migrating an xfs
filesystem between systems of differing endianness was design decision.
 And xfs userspace can't replay any log, native endian or not.  If it
could, then perhaps doing the swapping in userspace would be a migration
option.  If you're signing up to make xfs_repair replay logs, I'm sure
we'd welcome the patch.  :)

-Eric

> Thanks
> Eddy

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

[-- Attachment #1.1: Type: text/plain, Size: 161 bytes --]

>
> If you're signing up to make xfs_repair replay logs, I'm sure
> we'd welcome the patch.  :)
>

I'll think twice and try.

Thanks for the help! Eric, Lachlan

[-- Attachment #1.2: Type: text/html, Size: 278 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Lachlan McIlroy]

Hi Eddy,

CC'ing this to the xfs list.

----- "Eddy Zhao" <eddy.y.zhao@gmail.com> wrote:

> Hello Felix, Lachlan:
> 
> I find your names in 2.6.30 Changlog as XFS maintainer. Can you kindly
> take a look at the problem we are facing.
> 
> Follow the sequence below to reproduce the problem
> - write data on 2.6.28 system
> - unplug usb disk while writing
I don't recommend you pull the usb disk out while the filesystem is still
mounted (if you can avoid it).

> - plug usb disk to 2.6.10 system
> - mount filesystem. mount failed!! (refer error info at mail end)
> - repair filesystem. repair failed!! (refer to error info at mail end)
> - unplug usb disk, then plug usb disk to 2.6.28 system
> - mount filesystem. mount success
Okay good.  Looks like whatever the problem is it has been fixed.

> - unplug usb disk, then plug usb disk to 2.6.10 system
> - mount filesystem. mount success
> 
> We are hitting this because our products need to migrate data between
> them. And they are using either 2.6.28 or 2.6.10 kernel.
> 
> You can easily reproduce the problem follow the sequence above.
> 
> Is it XFS log "forward" compatible? Where's the problem? How can I fix
> it?
I would start by looking through the change history for fs/xfs/xfs_log_recover.c
and paying particular attention to anything to do with inode transactions.  Or
try some intermediate kernels and see if you can narrow the fix down to a set of
changes.

> 
> Thanks
> Eddy
> 
> 
> ---------------------------
> Error info on 2.6.10 system
> 
> 
> # mount /dev/sda1 /mnt/
> UDF-fs: No VRS found
> XFS mounting filesystem sda1
> Starting XFS recovery on filesystem: sda1 (dev: sda1)
> Filesystem "sda1": xfs_inode_recover: Bad inode magic number, dino ptr
> = 0xc8266700, dino bp = 0xc8281b40, ino = 0
Here we have log replay processing an inode and it's checking that what
is on disk (at the location where we are going to write the inode) is
actually an inode.  In this case what we read from the filesystem did
not have the magic number for an inode.  Hmm that 'ino = 0' doesn't seem
right either.

> Filesystem "sda1": XFS internal error xlog_recover_do_inode_trans(1)
> at line 2366 of file fs/xfs/xfs_log_recover.c. Caller 0xc01677c0
> [<c016532c>] (xlog_recover_process_data+0x0/0x1904) from [<c01677c0>]
> (xlog_do_recovery_pass+0x328/0x900)
> [<c0167498>] (xlog_do_recovery_pass+0x0/0x900) from [<c0167e8c>]
> (xlog_recover+0xf4/0x22c)
> [<c0167d98>] (xlog_recover+0x0/0x22c) from [<c0160cc8>]
> (xfs_log_mount+0x444/0x4bc)
> r9 = 00000004 r8 = C8295000 r7 = C8278000 r6 = 00000000
> r5 = C8BCAD80 r4 = C8C74DE0
> [<c0160884>] (xfs_log_mount+0x0/0x4bc) from [<c0169fd8>]
> (xfs_mountfs+0x7f0/0xac0)
> [<c01697e8>] (xfs_mountfs+0x0/0xac0) from [<c0170588>]
> (xfs_mount+0x618/0x6c4)
> [<c016ff70>] (xfs_mount+0x0/0x6c4) from [<c01830ac>]
> (vfs_mount+0x34/0x38)
> [<c0183078>] (vfs_mount+0x0/0x38) from [<c0182e60>]
> (linvfs_fill_super+0xa4/0x294)
> [<c0182dbc>] (linvfs_fill_super+0x0/0x294) from [<c00869b8>]
> (get_sb_bdev+0x128/0x184)
> r8 = C8239000 r7 = 00008000 r6 = C800C6C0 r5 = C8C57200
> r4 = C800C6DC
> [<c0086890>] (get_sb_bdev+0x0/0x184) from [<c018306c>]
> (linvfs_get_sb+0x1c/0x28)
> r8 = 00008000 r7 = C8238000 r6 = C032344C r5 = FFFFFFF4
> r4 = C8007960
> [<c0183050>] (linvfs_get_sb+0x0/0x28) from [<c0086bf8>]
> (do_kern_mount+0x5c/0xf4)
> [<c0086b9c>] (do_kern_mount+0x0/0xf4) from [<c009ecc0>]
> (do_mount+0x624/0x658)
> [<c009e69c>] (do_mount+0x0/0x658) from [<c009f144>]
> (sys_mount+0xa8/0xf4)
> [<c009f09c>] (sys_mount+0x0/0xf4) from [<c00299c0>]
> (ret_fast_syscall+0x0/0x2c)
> r7 = 00000015 r6 = 001CCBD8 r5 = BEFFFF8C r4 = 001CC308
> XFS: log mount/recovery failed: error 990
> XFS: log mount failed
> yaffs: dev is 8388609 name is "sda1"
> yaffs: Attempting MTD mount on 8.1, "sda1"
> yaffs: dev is 8388609 name is "sda1"
> yaffs: Attempting MTD mount on 8.1, "sda1"
> mount: mounting /dev/sda1 on /mnt/ failed: Invalid argument
> #
> #
> #
> #
> # xfs_repair /dev/sda1
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
> - zero log...
> ERROR: The filesystem has valuable metadata changes in a log which
> needs to
> be replayed. Mount the filesystem to replay the log, and unmount it
> before
> re-running xfs_repair. If you are unable to mount the filesystem, then
> use
> the -L option to destroy the log and attempt a repair.
> Note that destroying the log may cause corruption -- please attempt a
> mount
> of the filesystem before doing this.
> # mount
> rootfs on / type rootfs (rw)
> /dev/root on / type nfs
> (rw,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=7.7.7.1)
> none on /proc type proc (rw,nodiratime)
> none on /sys type sysfs (rw)
> none on /dev/pts type devpts (rw)
> none on /proc/bus/usb type usbfs (rw)

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eddy Zhao]

[-- Attachment #1.1: Type: text/plain, Size: 1025 bytes --]

>
> I don't recommend you pull the usb disk out while the filesystem is still
> mounted (if you can avoid it).
>

Doing that to emulate power loss scenario our device might experience.

>
> I would start by looking through the change history for
fs/xfs/xfs_log_recover.c
> and paying particular attention to anything to do with inode
transactions.
>

Not quite familiar with XFS code :(

>
> Or try some intermediate kernels and see if you can narrow the fix down to
a set of
> changes.
>

I'll try to bisect (It will take some time...)

>
> # mount /dev/sda1 /mnt/
> UDF-fs: No VRS found
> XFS mounting filesystem sda1
> Starting XFS recovery on filesystem: sda1 (dev: sda1)
> Filesystem "sda1": xfs_inode_recover: Bad inode magic number, dino ptr
> = 0xc8266700, dino bp = 0xc8281b40, ino = 0

Because XFS log is OK to 2.6.28 system, which means the log is correct in
itself.
Would it be easy for you to debug the problem by compare 2.6.10 log recovery
code fail point and the corresponding 2.6.28 log record?

Thanks
Eddy

[-- Attachment #1.2: Type: text/html, Size: 1221 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: BUG REPORT: XFS LOG FORWARD COMPATIBILITY PROBLEM

[Eric Sandeen]

Lachlan McIlroy wrote:
> Hi Eddy,
> 
> CC'ing this to the xfs list.
> 
> ----- "Eddy Zhao" <eddy.y.zhao@gmail.com> wrote:
> 
>> Hello Felix, Lachlan:
>>
>> I find your names in 2.6.30 Changlog as XFS maintainer. Can you kindly
>> take a look at the problem we are facing.
>>
>> Follow the sequence below to reproduce the problem
>> - write data on 2.6.28 system
>> - unplug usb disk while writing
> I don't recommend you pull the usb disk out while the filesystem is still
> mounted (if you can avoid it).
> 

Unless you have write barriers enabled and passing through to the USB
device, or write cache turned off on the USB device, this test may well
just be corrupting the log to an unreplayable state.

Although I can't explain why, w/o further modification, it seems to
mount again on .28 ...

-Eric

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