From: "Cláudio Martins" <ctpm@ist.utl.pt>
To: Chris Mason <chris.mason@oracle.com>
Cc: Diego Calleja <diegocg@gmail.com>,
Bill Pemberton <wfp5p@viridian.itc.virginia.edu>,
linux-btrfs@vger.kernel.org
Subject: Re: assertion failures
Date: Sun, 28 Feb 2010 03:05:00 +0000 [thread overview]
Message-ID: <20100228030500.732f9a05.ctpm@ist.utl.pt> (raw)
In-Reply-To: <20100226210853.GM12841@think>
On Fri, 26 Feb 2010 16:08:53 -0500 Chris Mason <chris.mason@oracle.com>=
wrote:
>=20
> The problem is that with a writeback cache, any write is likely
> to be missed on power failures. journalling in general requires some
> notion of being able to wait for block A to be on disk before you wri=
te
> block B, and that's difficult to do when the disk lies about what is
> really there ;)
>=20
Hi,
Has anyone managed to make a list of drive models which are suspect of
lying about what has really hit the disk surface, or of not hounouring
barriers?
Can anyone share any cases where your investigation turned positive
evidence that a drive model was defective in this respect?
This is so worrying that I think we should understand why are
manufacturers doing this: is it firmware bugs? Is it to inflate
benchmarks? Are they shoving crap on the cheaper drives' firmware to
force "enterprise" people to buy the more expensive SAS models?
If one could publish a list of known defective drives, maybe we could
put some shame on the manufacturers or even convince them to fix their
firmware. Failing that, we might at least be able to avoid the known
bad models.
Any insight into this subject will be appreciated.
Best regards
Cl=C3=A1udio
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-02-28 3:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-24 13:45 assertion failures Bill Pemberton
2010-02-25 0:40 ` Chris Mason
2010-02-25 14:04 ` Bill Pemberton
2010-02-25 18:28 ` Gustavo Alves
2010-02-26 16:13 ` Chris Mason
2010-02-26 16:15 ` Chris Mason
2010-02-26 19:57 ` Gustavo Alves
2010-02-26 21:10 ` Chris Mason
2010-02-26 21:26 ` Gustavo Alves
2010-02-26 16:17 ` Chris Mason
2010-02-26 16:41 ` Bill Pemberton
2010-02-26 17:59 ` Chris Mason
2010-02-26 18:11 ` Bill Pemberton
2010-02-26 19:09 ` Chris Mason
2010-02-26 20:43 ` Bill Pemberton
2010-02-26 20:49 ` Diego Calleja
2010-02-26 21:08 ` Chris Mason
2010-02-28 3:05 ` Cláudio Martins [this message]
2010-02-26 19:11 ` Mike Fedyk
2010-02-26 19:15 ` Chris Mason
2010-02-26 20:45 ` Bill Pemberton
2010-02-26 20:53 ` Chris Mason
2010-02-27 22:56 ` Bill Pemberton
2010-02-26 20:44 ` Bill Pemberton
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=20100228030500.732f9a05.ctpm@ist.utl.pt \
--to=ctpm@ist.utl.pt \
--cc=chris.mason@oracle.com \
--cc=diegocg@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wfp5p@viridian.itc.virginia.edu \
/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