From: Chris Mason <chris.mason@oracle.com>
To: Daniel J Blueman <daniel.blueman@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>,
Markus Trippelsdorf <markus@trippelsdorf.de>,
linux-btrfs@vger.kernel.org
Subject: Re: btrfs csum failed on git .pack file
Date: Wed, 9 Sep 2009 07:19:55 -0400 [thread overview]
Message-ID: <20090909111955.GA3473@think> (raw)
In-Reply-To: <6278d2220909090137k68d23db8p169c3a83d37d2a95@mail.gmail.com>
On Wed, Sep 09, 2009 at 09:37:42AM +0100, Daniel J Blueman wrote:
> >>
> >> http://www.ocztechnologyforum.com/forum/showthread.php?t=57516
> >
> > The issue is pretty much moot at this point, since OCZ support were not
> > really interested in providing any sort of real technical support to
> > find out what really caused this issue. My main worry was reliability of
> > these cheaper SSD drives, and that worry is still not resolved. If you
> > read the blog entries, I do comment on the apparently scary basic bugs
> > taht are still being fixed on the Indilinx controllers. I do expect some
> > basic level of data integrity from a consumer product and at least some
> > interest in resolving weird corruption issues if things go wrong. Since
> > OCZ cannot provide anything like that, I have a hard time recommending
> > these drives for anything but very casual use. Fast, cheap, reliable.
> > Pick any two.
> >
> > My drive was running 1.10 at the time of the problem.
>
> It looks like we need a small tool which performs patterned block I/O
> to the device, updating a checksum as it goes, and performing
> integrity sweeps at intervals, lower level than fsx. It must be
> trusted or not.
>
> I had a problem like this with nVidia CK804/MCP55 chipsets corrupting
> data under a triple-edge case workload.
Well, just use git ;) Apply a bunch of patches (say the mm tree) with
guilt and repack in a loop.
-chris
next prev parent reply other threads:[~2009-09-09 11:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-07 20:35 btrfs csum failed on git .pack file Markus Trippelsdorf
2009-09-08 20:00 ` Jens Axboe
2009-09-08 20:22 ` Markus Trippelsdorf
2009-09-08 20:32 ` Jens Axboe
2009-09-08 20:55 ` Tomasz Torcz
2009-09-09 6:55 ` Markus Trippelsdorf
2009-09-09 7:01 ` Jens Axboe
2009-09-09 7:23 ` Markus Trippelsdorf
2009-09-09 7:29 ` Jens Axboe
2009-09-09 8:18 ` Daniel J Blueman
2009-09-09 8:26 ` Jens Axboe
2009-09-09 8:37 ` Daniel J Blueman
2009-09-09 11:19 ` Chris Mason [this message]
2009-09-09 21:01 ` Oliver Mattos
2009-09-10 10:49 ` Bryan Østergaard
2009-09-08 21:53 ` Tracy Reed
2009-09-09 7:28 ` Gregory Maxwell
2009-09-17 5:05 ` Markus Trippelsdorf
2009-09-17 6:44 ` Jens Axboe
2009-09-17 9:04 ` Markus Trippelsdorf
2009-09-17 9:05 ` Jens Axboe
2009-09-17 12:15 ` Markus Trippelsdorf
2009-09-17 13:58 ` Markus Trippelsdorf
2009-09-17 17:00 ` Zach Brown
2009-09-17 17:10 ` Markus Trippelsdorf
2009-09-17 17:50 ` Tomasz Torcz
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=20090909111955.GA3473@think \
--to=chris.mason@oracle.com \
--cc=daniel.blueman@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=markus@trippelsdorf.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.