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: <20080311215601.GM23784@marowsky-bree.de>
Date:	Tue, 11 Mar 2008 22:56:01 +0100
From:	Lars Marowsky-Bree <lmb@...e.de>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Grzegorz Kulewski <kangur@...com.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

On 2008-03-11T03:50:18, Daniel Phillips <phillips@...nq.net> wrote:

> > as well. In fact, the most common reason for unorderly shutdowns are
> > kernel crashes, not power failures in my experience.
> What are you doing to your kernel?

I guess I'm being really vicious to them: I expose it to customers and
the real world.

My own servers also have uptimes of >400 days sometimes, and I wonder
what customers do to the poor things.

And yes, I'm not saying I don't see your point for specialised
deployments (filesystems which are easy to rebuild from scratch), but
transactional integrity is a requirement I'd rank really high on the
desirable list of features if I was you.

> > So "perfectly reliable if UPS power does not fail" seems a bit over the
> > top.
> It works for EMC :-)

Where they control the hardware and run a rather specialized OS as well,
not a general purpose system like Linux on "commodity" hardware ;-)

> In fact, replicating was one of the strategies I considered for this.
> But since it is a lot more work and will not perform as well as a
> simple sweep, I opted for the simple thing.  Which turned out to
> be pretty complex anyway.  You have to close all the same nasty
> races but with a considerably more complex base algorithm.  I think
> that better wait for version 2.0.

Ok, I see.

> By the way, I could use a hand debugging this thing.

I'm afraid with those properties it doesn't really meet my needs :-(

And, wouldn't a simpler way to achieve something similar not be to use
the plain Linux fs caching/buffers, just disabling forced write out
maybe via a mount option? This strikes me as similar to the effect I get
from remounting NFS (a)sync. Make the fs ignore fsync et al.

It would have the advantage of using all memory available for caching
and not otherwise requested, too. (And, of course, the downside of
making it hard to reserve cache space for a given fs explicitly, at
least now. But I'm sure the control group / container folks would love
that feature. ;-)

Regards,
    Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

--
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/