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: <20080315201815.GB4193@ucw.cz>
Date:	Sat, 15 Mar 2008 21:18:16 +0100
From:	Pavel Machek <pavel@....cz>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	david@...g.hm, David Newall <davidn@...idnewall.com>,
	Chris Friesen <cfriesen@...tel.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

Hi!

> > if you have a reliable UPS and are willing to rely on it to save your data 
> > take the identical hardware to what you are planning to use, but instead 
> > of using your driver just create a ramdisk and load it on boot and save 
> > the contents on shutdown.
> 
> Aha!  You are getting close.  Really, that is all ramback does.  It
> just handles some very difficult related issues efficiently, in such a
> way as to minimize any denial of service from complete loss of UPS
> power.  This is all just about using power management in a new way that
> gets higher performance.  But your battery power has to be reliable.
> Just make it so.  It is not difficult these days, or even particularly
> expensive.
> 
> I calculated somewhere along the line that it would take something like
> 17 minutes to populate the big Violin ramdisk initially, and 17 minutes
> to save it during a loss of line power event, during which UPS power
> must be not run out before ramback achieves disk sync or you will get
> file corruption.  (This rule was mentioned in my original post.)
> 
> All well and could, you can in fact do that with a pretty simple script.
> But in the initial 17 minutes your application may not read or write
> the ramdisk data and in the closing 17 minutes it may not write.  That
> knocks your system down to 4 nines, given one planned shutdown per year.
> Not good, not good at all.

Hmm, what happens if applications keep dirtying so much data you miss
your 17minute deadline?

Anyway...
 ext2
 + lots of memory
 + tweaked settings of kflushd (only write data older than 10 years)
 + just not using sync/fsync except during shutdown
 + find / | xargs cat 
 
...is ramback, right? Should have same performance, and you can still
read/write during that 17+17 minutes.

Ok, find | xargs might be slower... but we probably want to fix that
anyway....

It has big advantage: if you only tell kflushd to hold up writes for
an hour, you loose a little in performance and gain a lot in
reliability...

(If ext2+tweaks is slower than ramback, we have a bug to fix, I'm
afraid).
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/