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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080315205950.GA13012@1wt.eu>
Date:	Sat, 15 Mar 2008 21:59:50 +0100
From:	Willy Tarreau <w@....eu>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Newall <davidn@...idnewall.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

On Thu, Mar 13, 2008 at 11:14:39AM -0800, Daniel Phillips wrote:
> On Thursday 13 March 2008 06:22, Alan Cox wrote:
> > ...Ext3 cannot recover well from massive loss of intermediate
> > writes. It isn't a normal failure mode and there isn't sufficient fs
> > metadata robustness for this. A log structured backing store would deal
> > with that but all you apparently want to do is scream FUD at anyone who
> > doesn't agree with you.
> 
> Scream is an exaggeration, and FUD only applies to somebody who
> consistently overlooks the primary proposition in this design: that the
> battery backed power supply, computer hardware and Linux are reliable
> enough to entrust your data to them.  I say this is practical, you say
> it is impossible, I say FUD.
> 
> All you are proposing is that nobody can entrust their data to any
> hardware.  Good point.  There is no absolute reliability, only degrees
> of it.
> 
> Many raid controllers now have battery backed writeback cache, which
> is exactly the same reliability proposition as ramback, on a smaller
> scale.  Do you refuse to entrust your corporate data to such
> controllers?

RAID controllers do not have half a terabyte of RAM. Also, you are always
invited to choose between speed (write back) and reliability (write through).

Also, please note that the problem here is not related to the number of
nines of availability. This number only counts the ratio between uptime
and downtime. We're more facing a problem of MTBF, where the consequences
of a failure are hard to predict.

What I'm thinking about is that considering the fact that storage
technologies are moving towards SSD (and I think 2008 will be the
year of SSD), you should implement ordered writes (I've not said
write through) since there's no seek time on those devices. Thus
you will have the speed of RAM with the reliability of a properly
synced FS. If your system crashes once a week, it will not be a
problem anymore.

Willy

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