linux-kernel - Re: [ANNOUNCE] Ramback: faster than a speeding bullet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080314125656.GA7412@mit.edu>
Date:	Fri, 14 Mar 2008 08:56:56 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Benny Amorsen <benny+usenet@...rsen.dk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

On Fri, Mar 14, 2008 at 12:41:31PM +0100, Benny Amorsen wrote:
> Ric Wheeler <ric@....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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/