[Top] [All Lists]

Re: 2.6.32: dirty log written in incompatible format

To: xfs@xxxxxxxxxxx
Subject: Re: 2.6.32: dirty log written in incompatible format
From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
Date: Thu, 1 Apr 2010 00:01:36 -0700 (PDT)
In-reply-to: <alpine.DEB.2.01.1003312325110.5493@xxxxxxxxxxxxxxxxxx>
References: <alpine.DEB.2.01.1003312325110.5493@xxxxxxxxxxxxxxxxxx>
User-agent: Alpine 2.01 (DEB 1266 2009-07-14)
On Wed, 31 Mar 2010 at 23:45, Christian Kujau wrote:
> 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)

Oh, it seems to be an endianness issue indeed:


If only I had found this one /before/ writing to the list :-)


> 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
BOFH excuse #92:

Stale file handle (next time use Tupperware(tm)!)

<Prev in Thread] Current Thread [Next in Thread>