2.6.32: dirty log written in incompatible format

[Christian Kujau]

Hi folks,

recently I had some hardware-related trouble with this external dual disk 
enclosure, which is usually connected vua USB to a powerpc32 machine 
running mostly vanilla kernels. I think the USB port is dead so I 
had to take the the enclosure into another box - this time via Firewire to 
a Intel Mac (2.6.32-18 ubuntu kernel)

One of the disks (same model, same GPT partitioning) is formatted with 
ext4 (which is fine), the other one with xfs - and I can't mount the xfs 
disk (partition) any more:

disko# mount -t xfs /dev/mapper/wdc1 /mnt/wdc1
mount: /dev/mapper/wdc1: can't read superblock

SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
XFS mounting filesystem dm-0
Starting XFS recovery on filesystem: dm-0 (logdev: internal)
XFS: dirty log written in incompatible format - can't recover
XFS: log mount/recovery failed: error 5
XFS: log mount failed

When the disk was mounted the last time (usb, powerpc32) an rsync process 
was busy copying data between directories and "rm" was also involved - 
then the disk issues kicked in again (USB disconnect, etc) and XFS was 
shutting down, of course.

However, the powerpc32 machine already was on 2.6.34-rc2 (I'm tracking
-rc versions, so it was running -rc1 before ...and so on) - could it be 
that the 2.6.32 Ubuntu kernel doesn't understand the dirty log from 
2.6.34-rc2? Or is it arch related?

FWIW, xfs_check advises to mount the filesystem first, xfs_repair *would* 
do quite a few operations on the filesystem. I've put a few more details 
here: http://nerdbynature.de/bits/2.6.32/xfs/

Oh, and the whole xfs (resp. ext4) stuff is on top of dm-crypt/LUKS, but 
it's not a keying issue, as I can clearly see the XFS partition.

Thanks for reading (and replying!)
Christian.
-- 
BOFH excuse #315:

The recent proliferation of Nuclear Testing