public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: markgw@sgi.com
Cc: Richard Ems <Richard.Ems@cape-horn-eng.com>,
	xfs@oss.sgi.com, Bill O'Donnell <billodo@sgi.com>
Subject: Re: XFS internal error xfs_btree_check_lblock
Date: Mon, 21 Jul 2008 21:07:31 -0500	[thread overview]
Message-ID: <488540E3.7030702@sandeen.net> (raw)
In-Reply-To: <48851E5C.8010005@sgi.com>

Mark Goodwin wrote:
> 
> Eric Sandeen wrote:
>> Richard Ems wrote:
>>> Mark Goodwin wrote:
>>>> Hi Richard,
>>>>
>>>> this looks like XFS b-tree corruption of some sort. We have some patches
>>>> that should help here. The patches are being back-ported to SLES10 and
>>>> should also apply to OpenSUSE. We should have something ready early next
>>>> week.
>>> Thanks Mark. The most annoying thing is that, after many repairs, it's
>>> working again! But my big question is ... for how long? How stable is
>>> the filesystem now? Should I better recreate it? WHY did this happen?
>>> Why did the FS fail again after some repairs?  8(
>>>
>>> Where can I get more info about these patches? Is there a developer
>>> mailing list? Or some webpage to follow the development progress?
>> This *is* the developer mailing list, and I am honestly a bit frustrated
>> that said bugs & patches are not being aired & reviewed in public, honestly.
> 
> I'm sorry Eric for not being very clear. Nothing "secret" going on here,
> nor intended. The problems have all been reported (or mostly, but I'm
> not going to report every problem seen by every SGI customer). The issues
> I'm referring to are extent list corruption (causing hangs), bmap corruption
> due to failed allocs in full AGs (and locking hierarchy issues), and invalid
> btree cursors following btree splits. Lachlan and others have posted patches
> for all of these over the past couple of months (I'll dredge the archives
> and post the references if you want). The changes are all reviewed, checked
> in and available in CVS. Some made it into .26 and others will appear in .27
> in a day or two.

Great.  From your earlier reply I had the impression that they were
patches still internal to SGI - which of course SGI has every right to
do, but patch reviews have the potential to be better if more eyes can
see them - but if they're all already out there on the list, then thanks
and sorry for the noise.  :)

-Eric

  reply	other threads:[~2008-07-22  2:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-18 14:55 XFS internal error xfs_btree_check_lblock Richard Ems
2008-07-19  3:08 ` Mark Goodwin
2008-07-19 16:36   ` sandeen
2008-07-21  9:33   ` Richard Ems
2008-07-21 16:11     ` Eric Sandeen
2008-07-21 23:40       ` Mark Goodwin
2008-07-22  2:07         ` Eric Sandeen [this message]
2008-07-21 16:06   ` Russell Cattelan
2008-07-22  3:24     ` Mark Goodwin
2008-07-22 10:49       ` Richard Ems
2008-07-22 11:27         ` Mark Goodwin
2008-07-22 15:22           ` Eric Sandeen

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=488540E3.7030702@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=Richard.Ems@cape-horn-eng.com \
    --cc=billodo@sgi.com \
    --cc=markgw@sgi.com \
    --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