xfs
[Top] [All Lists]

Re: Call trace with 2.6.27.39

To: aluno3 <aluno3@xxxxxxxxxxxxxx>
Subject: Re: Call trace with 2.6.27.39
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 30 Dec 2009 09:00:36 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4B3A47F8.2020100@xxxxxxxxxxxxxx>
References: <4B3A47F8.2020100@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Dec 29, 2009 at 07:18:32PM +0100, aluno3 wrote:
> Hi
>  
> I have tested kernel 2.6.27.39 with fsstress, LVM, DD and snapshots and after 
> a few hours I got call trace.I had 2 volumes and 10 snapshots for each 
> volume.I created and deleted these snapshots from time to time and wrote to 
> origin volumes with use DD from /dev/zero.Fsstress was run for 1 volume.
> 
> 
> Filesystem "dm-41": xfs_log_force: error 5 returned.

What were the errors in the log before this? i.e. why did
xfs_log_force() get an EIO error? It sounds like there's something
already gone wrong before this point.

> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> IP: [<ffffffff802e99c3>] bdevname+0x3/0x20
....
> Process xfslogd/0 (pid: 404, threadinfo ffff88021d956000, task 
> ffff88021fafd890)
> Stack:  ffffffff803e7526 ffff880028046970 ffffffff80817020 ffff88021d957e38
>  00000000ffff8b92 ffff88021fafdac0 ffff88021fafd890 000000001d957eb8
>  ffff880207fe8800 ffff88007fbf6cc0 ffff88021d937bc8 ffff88021d937bc8
> Call Trace:
>  [<ffffffff803e7526>] ? xfs_ioerror_alert+0x56/0xc0
>  [<ffffffff803d5060>] ? xlog_recover_iodone+0x40/0x90
>  [<ffffffff803eaa60>] ? xfs_buf_iodone_work+0x0/0x80

This has died during log recovery (on a different filesytem?), which
implies that a buffer has not been set up properly with a buftarg or
mount stucture. I can't see how that would happen from the code
because each place that explicitly sets xlog_recover_iodone() as the
completion also sets the bp->b_mount correctly. Still, there's been
an IO error of some kind to get to xfs_ioerror_alert(), so it comes
back to whether there were errors reported before this failure?

Also, were you mounting a snapshot when this occurred? If so, you
shouldn't be doing log recovery on a snapshot because that writes to
the snapshot - you should mount them with the "ro,norecovery"
options to avoid this.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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