xfs
[Top] [All Lists]

Re: another problem with latest code drops

To: Lachlan McIlroy <lachlan@xxxxxxx>
Subject: Re: another problem with latest code drops
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 16 Oct 2008 17:02:47 +1100
Cc: xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <48F6A19D.9080900@sgi.com>
Mail-followup-to: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
References: <48F6A19D.9080900@sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Oct 16, 2008 at 12:06:21PM +1000, Lachlan McIlroy wrote:
> fsstress started reporting these errors
>
> fsstress: check_cwd failure
> fsstress: check_cwd failure
> fsstress: check_cwd failure
> fsstress: check_cwd failure
> fsstress: check_cwd failure
> ...
>
> The filesystem is mounted on /mnt/data but the mount point is now toast.
>
> wipeout:/mnt # mount
> ...
> /dev/mapper/dm0 on /mnt/data type xfs (rw,logdev=/dev/ram0,nobarrier)
>
>
> wipeout:/mnt # ls -alF
> /bin/ls: data: Input/output error
> total 4
> drwxr-xr-x  6 root root   57 Aug  8 03:09 ./
> drwxr-xr-x 21 root root 4096 Oct 15 11:56 ../
> ?---------  0 root root    0 Dec 31  1969 data
> drwxr-xr-x  2 root root    6 Jul 16 08:21 home/

I bet the filesystem has been shut down....

[snip]

> Oct 16 09:54:54 wipeout kernel: [79179.449760] Filesystem "dm-0": XFS 
> internal error xfs_trans_cancel at line 1164 of file fs/xfs/xfs_trans.c.  
> Caller 0xffffffff8118
> d422
> Oct 16 09:54:54 wipeout kernel: [79179.449773] Pid: 6679, comm: fsstress Not 
> tainted 2.6.27-rc8 #192
> Oct 16 09:54:54 wipeout kernel: [79179.449775] Oct 16 09:54:54 wipeout 
> kernel: [79179.449775] Call Trace:
> Oct 16 09:54:54 wipeout kernel: [79179.449784]  [<ffffffff81176d54>] 
> xfs_error_report+0x3c/0x3e
> Oct 16 09:54:54 wipeout kernel: [79179.449789]  [<ffffffff8118d422>] ? 
> xfs_rename+0x703/0x745
> Oct 16 09:54:54 wipeout kernel: [79179.449795]  [<ffffffff8118e9cb>] 
> xfs_trans_cancel+0x5f/0xfc
> Oct 16 09:54:54 wipeout kernel: [79179.449799]  [<ffffffff8118d422>] 
> xfs_rename+0x703/0x745
> Oct 16 09:54:54 wipeout kernel: [79179.449805]  [<ffffffff8119d4b2>] 
> xfs_vn_rename+0x5d/0x61
> Oct 16 09:54:54 wipeout kernel: [79179.449810]  [<ffffffff810ab449>] 
> vfs_rename+0x2b2/0x42e
> Oct 16 09:54:54 wipeout kernel: [79179.449815]  [<ffffffff810ad0f2>] 
> sys_renameat+0x16d/0x1e3
> Oct 16 09:54:54 wipeout kernel: [79179.449821]  [<ffffffff810a66d2>] ? 
> sys_newstat+0x31/0x3c
> Oct 16 09:54:54 wipeout kernel: [79179.449826]  [<ffffffff810ad17e>] 
> sys_rename+0x16/0x18
> Oct 16 09:54:54 wipeout kernel: [79179.449831]  [<ffffffff8100bf3b>] 
> system_call_fastpath+0x16/0x1b
> Oct 16 09:54:54 wipeout kernel: [79179.449835] Oct 16 09:54:54 wipeout 

Ah, yes. A shutdown in a directory transaction. Have you applied the
fix to the directory block allocation transaction accounting that was one
of the last patches I posted?

If so, then there's some other problem in that code that we'll
need a reproducable test case to be able to find....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx


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