From: Ric Wheeler <ric@emc.com>
To: Theodore Tso <tytso@mit.edu>,
Benny Amorsen <benny+usenet@amorsen.dk>,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet
Date: Fri, 14 Mar 2008 11:47:04 -0400 [thread overview]
Message-ID: <47DA9DF8.5010600@emc.com> (raw)
In-Reply-To: <20080314125656.GA7412@mit.edu>
Theodore Tso wrote:
> On Fri, Mar 14, 2008 at 12:41:31PM +0100, Benny Amorsen wrote:
>> Ric Wheeler <ric@emc.com> writes:
>>
>>> The only really safe default is to disable the write cache by default
>>> or possibly dynamically disable the write cache when barriers are not
>>> supported by a drive. Both have a severe performance impact and I am
>>> not sure that for most casual users it is a good trade.
>> So people ARE running their disks in a mode similar to Ramback.
>
> Similar, but not as aggressive. Remember, the size of the write cache
> on the hard drive is relatively small (small number of megabytes), and
> the drive generally is relatively aggressive about getting the data
> out to the platters; it's probably not going to keep unwritten data on
> the platters for minutes or hours at a time, let alone days. Of
> course, unless you use write barriers or some kind of explicit write
> ordering, it's going to write stuff out in an order which is
> convenient to the hard drive, not necessarily an order convenient to
> the filesystem.
You get 8-16MB per disk with most drives today. Different firmware will
do different things about how aggressively they push the data out to
platter.
> Also, if the system crashes, you don't lose the data in hard drive's
> write cache, where as the data in Ramback is likely gone. And Ramback
> is apaprently keeping potentially several gigabytes dirty in memory
> and *not* writing it out very aggressively. So the exposure is one of
> degree.
>
> In practice, it's interesting that we've had so few people reporting
> massive data loss despite the lack of the use of write barriers.
> Sure, in absolutely critical situations, it's not a good thing; but if
> I had a mail server, where I really wanted to make sure I didn't lose
> any e-mail, having a small UPS which could keep the server going for
> just a few minutes so it could do a controlled shutdown on a power
> failure is probably a better engineering solution from a
> cost/benefit/performance point of view, compared to turning on write
> barriers and taking up to two orders of magnitude worth of performance
> hit.
>
> - Ted
Most people don't see power outages too often - maybe once a year? When
you travel with a laptop, we are always effectively on a UPS so that
will also tend to mask this issue.
The ingest rate at the time of a power hit makes a huge difference as
well - basically, pulling the power cord when a box is idle is normally
not harmful. Try that when you are really pounding on the disks and you
will see corruptions a plenty without barriers ;-)
One note - the barrier hit for apps that use fsync() is just half an
order of magnitude (say 35 files/sec instead of 120 files/sec). If you
don't fsync() each file, the impact is lower still.
Still expensive, but might be reasonable for home users on a box with
family photos, etc.
ric
next prev parent reply other threads:[~2008-03-14 15:47 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-10 6:46 [ANNOUNCE] Ramback: faster than a speeding bullet Daniel Phillips
2008-03-10 7:51 ` Grzegorz Kulewski
2008-03-10 8:23 ` Daniel Phillips
2008-03-10 9:37 ` Alan Cox
2008-03-10 21:03 ` Lars Marowsky-Bree
2008-03-11 11:14 ` Daniel Phillips
2008-03-11 11:23 ` Lars Marowsky-Bree
2008-03-11 11:50 ` Daniel Phillips
2008-03-11 17:26 ` Chris Friesen
2008-03-11 19:56 ` Daniel Phillips
2008-03-11 20:53 ` Willy Tarreau
2008-03-12 8:17 ` Daniel Phillips
2008-03-12 14:41 ` Mike Snitzer
2008-03-13 20:34 ` Rik van Riel
2008-03-14 2:20 ` Daniel Phillips
2008-03-11 21:56 ` Lars Marowsky-Bree
2008-03-11 23:02 ` Daniel Phillips
2008-03-12 13:25 ` Benny Amorsen
2008-03-12 13:30 ` Alan Cox
2008-03-13 15:29 ` Benny Amorsen
2008-03-14 9:30 ` Pavel Machek
2008-03-14 11:07 ` Ric Wheeler
2008-03-14 11:41 ` Benny Amorsen
2008-03-14 12:12 ` Ric Wheeler
2008-03-14 12:56 ` Theodore Tso
2008-03-14 15:47 ` Ric Wheeler [this message]
2008-03-14 16:49 ` Theodore Tso
2008-03-14 17:04 ` Ric Wheeler
2008-03-14 18:03 ` david
2008-03-14 19:03 ` writeback cache dangers " Pavel Machek
2008-03-14 19:29 ` Theodore Tso
2008-03-13 9:15 ` Matthias Schniedermeyer
2008-03-11 23:30 ` Daniel Phillips
2008-03-13 13:27 ` Ric Wheeler
2008-03-13 19:02 ` Daniel Phillips
2008-03-13 19:12 ` Ric Wheeler
2008-03-13 19:38 ` Daniel Phillips
2008-03-11 4:23 ` Daniel Phillips
2008-03-10 9:22 ` Alan Cox
2008-03-10 19:01 ` Rik van Riel
2008-03-11 4:28 ` Daniel Phillips
2008-03-11 3:50 ` Daniel Phillips
2008-03-11 13:32 ` Artur Skawina
2008-03-11 14:31 ` Artur Skawina
2008-03-12 13:11 ` Alan Cox
2008-03-12 17:29 ` Daniel Phillips
2008-03-12 18:11 ` Chris Friesen
2008-03-12 22:56 ` Daniel Phillips
2008-03-13 5:45 ` David Newall
2008-03-13 6:17 ` Daniel Phillips
2008-03-13 6:30 ` David Newall
2008-03-13 6:50 ` Daniel Phillips
2008-03-13 7:05 ` David Newall
2008-03-13 7:13 ` Daniel Phillips
2008-03-15 13:32 ` Pavel Machek
2008-03-15 20:22 ` Daniel Phillips
2008-03-15 21:33 ` Pavel Machek
2008-03-15 21:47 ` Daniel Phillips
2008-03-13 6:32 ` david
2008-03-13 7:12 ` Daniel Phillips
2008-03-13 7:55 ` david
2008-03-13 8:06 ` Daniel Phillips
2008-03-13 8:39 ` david
2008-03-13 9:16 ` Daniel Phillips
2008-03-13 16:25 ` david
2008-03-13 19:32 ` Daniel Phillips
2008-03-13 19:50 ` David Newall
2008-03-13 20:03 ` Daniel Phillips
2008-03-14 17:53 ` Jeff Moyer
2008-03-15 20:26 ` Pavel Machek
2008-03-15 20:40 ` Mike Snitzer
2008-03-15 21:05 ` Daniel Phillips
2008-03-15 20:18 ` Pavel Machek
2008-03-15 20:51 ` Daniel Phillips
2008-03-13 9:49 ` Daniel Phillips
2008-03-13 5:39 ` David Newall
2008-03-13 6:14 ` Daniel Phillips
2008-03-13 13:22 ` Alan Cox
2008-03-13 19:14 ` Daniel Phillips
2008-03-13 20:27 ` Rik van Riel
2008-03-14 2:23 ` Daniel Phillips
2008-03-14 5:22 ` David Newall
2008-03-14 5:42 ` Daniel Phillips
2008-03-14 14:00 ` John Stoffel
2008-03-15 20:59 ` Willy Tarreau
2008-03-15 20:56 ` Alan Cox
2008-03-15 21:25 ` Daniel Phillips
2008-03-15 21:08 ` Alan Cox
2008-03-15 21:51 ` Daniel Phillips
2008-03-15 21:17 ` Daniel Phillips
2008-03-15 21:03 ` Alan Cox
2008-03-15 22:00 ` Daniel Phillips
2008-03-15 23:05 ` Alan Cox
2008-03-16 21:57 ` Daniel Phillips
2008-03-16 21:55 ` Alan Cox
2008-03-16 22:36 ` Daniel Phillips
2008-03-16 22:46 ` Alan Cox
2008-03-16 23:39 ` Daniel Phillips
2008-03-17 11:53 ` Alan Cox
2008-03-17 1:31 ` David Newall
2008-03-17 2:42 ` Daniel Phillips
2008-03-17 3:59 ` david
2008-03-17 5:52 ` Daniel Phillips
2008-03-17 6:49 ` david
2008-03-17 8:16 ` Daniel Phillips
2008-03-17 10:39 ` Alan Cox
2008-03-17 13:52 ` Ric Wheeler
2008-03-17 14:42 ` david
2008-03-17 17:23 ` david
2008-03-17 17:30 ` Willy Tarreau
[not found] ` <200803180233.10156.phillips@phunq.net>
2008-03-18 13:03 ` David Newall
2008-03-18 16:36 ` david
2008-03-31 11:40 ` Daniel Phillips
2008-04-01 0:28 ` david
2008-04-01 4:07 ` Daniel Phillips
2008-04-01 4:23 ` david
2008-04-01 6:08 ` Daniel Phillips
2008-03-18 13:57 ` Alan Cox
2008-03-31 11:39 ` Daniel Phillips
2008-03-17 7:14 ` David Newall
2008-03-17 8:25 ` Daniel Phillips
2008-03-17 18:56 ` David Newall
2008-03-23 9:33 ` Pavel Machek
2008-03-23 20:44 ` Daniel Phillips
2008-03-15 21:54 ` Willy Tarreau
2008-03-15 22:33 ` Daniel Phillips
2008-03-15 23:22 ` david
2008-03-15 23:57 ` Krzysztof Halasa
2008-03-15 23:22 ` Willy Tarreau
2008-03-16 3:33 ` Daniel Phillips
2008-03-16 5:24 ` David Newall
2008-03-16 12:49 ` Ingo Oeser
2008-03-16 6:56 ` Willy Tarreau
2008-03-16 22:12 ` Krzysztof Halasa
2008-03-16 13:14 ` Alan Cox
2008-03-16 19:04 ` Theodore Tso
2008-03-16 22:02 ` Krzysztof Halasa
2008-03-15 23:18 ` Bernd Eckenfels
2008-03-16 5:42 ` David Newall
2008-03-16 20:48 ` Daniel Phillips
2008-03-16 22:15 ` Krzysztof Halasa
2008-03-16 22:38 ` Daniel Phillips
2008-03-16 23:08 ` Krzysztof Halasa
2008-03-16 23:43 ` Daniel Phillips
2008-03-10 14:51 ` Artur Skawina
2008-03-10 18:49 ` Chris Snook
2008-03-11 5:06 ` Greg KH
2008-03-11 5:22 ` Daniel Phillips
2008-03-11 5:48 ` david
2008-03-11 6:27 ` Greg KH
2008-03-12 12:01 ` tvrtko.ursulin
2008-03-12 17:27 ` Daniel Phillips
[not found] <OFA00954A4.45F32CA2-ON8025740B.005D7B40-8025740B.005EECA6@sophos.com>
2008-03-13 19:34 ` Daniel Phillips
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=47DA9DF8.5010600@emc.com \
--to=ric@emc.com \
--cc=benny+usenet@amorsen.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.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 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.