lkml.org 
[lkml]   [2008]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] Ramback: faster than a speeding bullet
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


\
 
 \ /
  Last update: 2008-03-14 16:51    [W:0.128 / U:4.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site