From: Dave Chinner <david@fromorbit.com>
To: "aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl>
Cc: xfs@oss.sgi.com
Subject: Re: XFS problems with 2.6.27
Date: Thu, 18 Feb 2010 19:44:46 +1100 [thread overview]
Message-ID: <20100218084446.GZ28392@discord.disaster> (raw)
In-Reply-To: <4B7CF542.6090501@poczta.onet.pl>
On Thu, Feb 18, 2010 at 09:07:30AM +0100, aluno3@poczta.onet.pl wrote:
> Can somebody help with this problem? If you need more details, please
> let me know.
You've got lots of problems.
> > Hello!
> >
> > We"ve got two different systems running with XFS, one of them is
> > publishing shares via NFS, the other via Samba. We've recently
> > encountered filesystem issues on both servers, and received the
> > following call traces. They look very much alike.
> >
> > Are these something you are familiar with? We'd like to at least
> > establish that the problem really is with XFS... We don't really have
> > the possibility to update the kernels (2.6.27.10) on those machines, but
> > we can possibly apply patches etc. These systems are usually under a
> > fairly high load and host a large number of files.
> >
> >
> > Filesystem "dm-16": Disabling barriers, trial barrier write failed
> > XFS mounting filesystem dm-16
> > Starting XFS recovery on filesystem: dm-16 (logdev: internal)
> > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1590 of file
> > fs/xfs/xfs_alloc.c. Caller 0xffffffff80398ca7
> > Pid: 15745, comm: mount Not tainted 2.6.27.10
> > #24
That's a corrupt free space tree => xfs_repair.
> > NFSD: starting 90-second grace period
> > bootsplash: status on console 0 changed to off
> > usb 3-2: USB disconnect, address 2
> > 00000000: 00 00 00 00 00 28 00 e0 00 00 00 00 00 00 00 00 .....(..........
> > Filesystem "dm-20": XFS internal error xfs_da_do_buf(2) at line 2112 of
> > file fs/xfs/xfs_da_btree.c. Caller 0xffffffff803b34b4
> > Pid: 23023, comm: smbd Not tainted 2.6.27.10
> > #24
That's a corrupt directory block. The output there bears no
resemblance to an XFS directory header - you might be hitting the
problem where DM fails to mark a cancelled readahead bio correctly
and XFS detects it in xfs_da_do_buf() as an uninitialised buffer
and shuts down the filesystem.
I'd say run repair and if it doesn't find any directory corruption,
you need to get the DM and XFS fixes for the cancelled readhead bios
backported.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2010-02-18 8:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-09 15:18 XFS problems with 2.6.27 aluno3
2010-02-18 8:07 ` aluno3
2010-02-18 8:44 ` Dave Chinner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100218084446.GZ28392@discord.disaster \
--to=david@fromorbit.com \
--cc=aluno3@poczta.onet.pl \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox