xfs
[Top] [All Lists]

RE: FW: log mount/recovery failed

To: "'Daniel Moore'" <dxm@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: FW: log mount/recovery failed
From: "Justin Hamilton" <Justin@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 23 Jul 2001 06:37:13 -0400
Cc: <linux-xfs@xxxxxxxxxxx>
Importance: Normal
In-reply-to: <200107230617.QAA50351@snort.melbourne.sgi.com>
Organization: Linux-TechSupport.Com
Reply-to: <Justin@xxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Here is the xfs_logprint:

[root@Voyager /]# xfs_logprint /dev/vg04/lv_movies 
xfs_logprint:
    data device: 0x3a07
    log device: 0x3a07 daddr: 10485792 length: 9600

Header 0xc wanted 0xfeedbabe
**********************************************************************
* ERROR: header cycle=12          block=1463                         *
**********************************************************************
Bad log record header

So somehow, it looks like the log is getting clobbered.

Before I run the xfs_repair, is there any other info that will be useful
to ensuring this get fixed?

Justin

-----Original Message-----
From: owner-linux-xfs@xxxxxxxxxxx [mailto:owner-linux-xfs@xxxxxxxxxxx]
On Behalf Of Daniel Moore
Sent: Monday, July 23, 2001 2:18 AM
To: Justin@xxxxxxxxxxxxxxxxxxxxx
Cc: linux-xfs@xxxxxxxxxxx
Subject: Re: FW: log mount/recovery failed 

"Justin Hamilton" writes:
 => Here's the logprint of my filesystem:
 => 
 => [root@Voyager /]# xfs_logprint -t /dev/vg04/lv_movies 
 => xfs_logprint:
 =>     data device: 0x3a07
 =>     log device: 0x3a07 daddr: 10485792 length: 9600
 => 
 => * ERROR: mismatched uuid in log
 => *            SB : 5a0fad57-e48c-41be-bee6-308250aecd17
 => *            log: 00000100-0000-0100-0000-a00000000000
 => Bad log
 => 
 => Looks like a problem... How do I set the UUID for the log?

You can't and shouldn't have to set the uuid for the log. It gets
written out in every log header and should always match the one in the
SB. It looks like the log may have been clobbered somehow. You could try
xfs_logprint with no '-t' and check out the uuids in the other log
records. Maybe that would tell you something...

If all else fails, you can run 'xfs_repair'. It will erase the log (NOT
play it back) and repair the filesystem to a consistent state which
should get you going again.

But it would be nice to know what's going on here since this shouldn't
happen.


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