xfs
[Top] [All Lists]

Re: bad log entries after remount with XFS over MD in 2.6

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: bad log entries after remount with XFS over MD in 2.6
From: Andi Kleen <ak@xxxxxxxxxxxxx>
Date: 22 Aug 2003 11:30:43 +0200
Date: Fri, 22 Aug 2003 11:30:43 +0200
Cc: Andi Kleen <ak@xxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20030822002801.GB823@frodo>
References: <20030821194432.GA12755@averell> <20030822002801.GB823@frodo>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.1i
[I notice the subject is misleading. It was just an normal
umount, not a remount]

On Fri, Aug 22, 2003 at 10:28:01AM +1000, Nathan Scott wrote:
> hi Andi,
> 
> On Thu, Aug 21, 2003 at 09:44:32PM +0200, Andi Kleen wrote:
> > 
> > I have an XFS over a MD-0 (RAID-0) device stripped over two SCSI disks.
> > 
> > The problem is that after a reboot the mount often fails with
> > "bad clientid". This happens both when the file system was cleanly
> > unmounted (even explicitely before shutdown) or when the machine
> > crashed.
> > 
> > I can remount again when I run xfs_repair -L first, but that always
> > takes a long time. Also it tends to find some old files and reconnect
> > them to lost+found.
> 
> FWIW, you can use xfs_db to just write a fresh log, might be

I currently use xfs_repair -L and then quick Ctrl-C.

Not very nice, but seems to work.

> quicker for you in this situation.  Use the "uuid rewrite"
> command.  Oh, actually I might have added the dirty log check

Thanks for the hint.

> in there too (ala xfs_repair) - you might need to hack it a
> bit (maybe add a -L to the uuid command) - I can't remember
> off the top of my head.
> 
> > The log dump starts with an umount record, but XFS seems to read beyond
> > that and find bogus log entries and then fail on them.
> > Why does it not stop on the first?
> 
> Cos the first may not be the last.  ;)
> 
> (mount; unmount; mount; unmount; mount; ...)
> 
> Recovery doesn't really look inside the payload of each log record
> until it has a good idea of exactly where the log head and tail are.
> 
> Other than this I have no hints.  I don't see this behaviour on
> non-MD devices just as a data point.  From your logprint it looks

Yes, non-MD works fine for me too.

> like the log writes are the problem (as opposed to the log reads
> that recovery does).  We do funky stuff there - write different
> size chunks at arbitrary 512 byte offsets... has caused problems
> for busted drivers in the past, maybe something along those lines
> again.

Possible yes. MD hasn't been exactly trouble free in 2.5 so far with
the new BIO code.

The log is never cleared on recovery right?

-Andi


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