public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Tracy Reed <treed@ultraviolet.org>
To: Chris Mason <chris.mason@oracle.com>
Cc: mroconnor@oel.state.nj.us, linux-btrfs@vger.kernel.org
Subject: Re: kernel bug in file-item.c
Date: Wed, 29 Apr 2009 12:32:07 -0700	[thread overview]
Message-ID: <20090429193207.GK26602@tracyreed.org> (raw)
In-Reply-To: <1241030419.20099.55.camel@think.oraclecorp.com>

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Wed, Apr 29, 2009 at 02:40:19PM -0400, Chris Mason spake thusly:
> Well, then I'm surprised btrfs doesn't crash more violently and more
> often ;)

Note that this will be a problem that btrfs must properly manage. And
it must be done MUCH better than a certain previously semi-popular
filesystem did. The expectation needs to be set that due to the much
more complicated in-memory structures being used by modern filesystems
that your hardware must be rock solid or you will get filesystem
corruption. I ran the other filesystem on hundreds of machines with no
problem (all solid hardware) but I regularly run into people (just
this morning, for example) who swear that *every*single*time* they
created a filesystem with that other fs it was corrupted in a short
amount of time. It just doesn't add up. First impressions and early
rumors can doom a filesystem (although clearly other factors such as
personalities and politics can be at play as well).

> Do you think you're hitting a memtest bug or is the HW really bad?

A bug in memtest? It's been rock solid for years hasn't it? Maybe some
new memory configuration or MMU might freak it out. Seems quite
unlikely compared to the chances of actually having bad RAM.

-- 
Tracy Reed
http://tracyreed.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2009-04-29 19:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 17:39 kernel bug in file-item.c Marc R. O'Connor
2009-04-28 19:23 ` Chris Mason
2009-04-28 19:30   ` Marc R. O'Connor
2009-04-29 16:04   ` Marc R. O'Connor
2009-04-29 17:53     ` Chris Mason
2009-04-29 18:21       ` Marc R. O'Connor
2009-04-29 18:30         ` Chris Mason
2009-04-29 18:38           ` Marc R. O'Connor
2009-04-29 18:40             ` Chris Mason
2009-04-29 18:46               ` Marc R. O'Connor
2009-04-29 18:50               ` Zach Brown
2009-04-29 19:04                 ` Marc R. O'Connor
2009-04-30  7:23                   ` Dmitri Nikulin
2009-04-29 19:32               ` Tracy Reed [this message]
2009-04-30  9:08                 ` Paul Komkoff
2009-04-30 16:54                   ` Tracy Reed
2009-05-01  2:13                     ` Dmitri Nikulin

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=20090429193207.GK26602@tracyreed.org \
    --to=treed@ultraviolet.org \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mroconnor@oel.state.nj.us \
    /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