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]

Date:	Sat, 15 Mar 2008 13:47:00 -0800
From:	Daniel Phillips <phillips@...nq.net>
To:	Pavel Machek <pavel@....cz>
Cc:	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

On Saturday 15 March 2008 14:33, Pavel Machek wrote:
> On Sat 2008-03-15 12:22:47, Daniel Phillips wrote:
> > On Saturday 15 March 2008 06:32, Pavel Machek wrote:
> > > On Wed 2008-03-12 22:50:55, Daniel Phillips wrote:
> > > > On Wednesday 12 March 2008 23:30, David Newall wrote:
> > > > > Daniel Phillips wrote:
> > > > > >> Your idea seems predicated on throwing large amounts of RAM at the
> > > > > >> problem.  What I want to know is this: Is it really 25 times faster than
> > > > > >> ext3 with an equally huge buffer cache?
> > > > > >
> > > > > > Yes.
> > > > > 
> > > > > Well, that sounds convincing.  Not.  You know this how?
> > > > 
> > > > By measuring it.  time untar -xf linux-2.2.26.tar; time sync
> > > 
> > > Thats cheating. Your ramback ignores sync.
> > > 
> > > Just time it against ext3 _without_ doing the sync. That's still more
> > > reliable than what you have.
> > 
> > No, that allows ext3 to cheat, because ext3 does not supply any means
> > of flushing its cached data to disk in response to loss of line power,
> > and then continuing on in a "safe" mode until line power comes back.
> 
> Ok, it seems like "ignore sync/fsync unless on UPS power" is what you
> really want? That should be easy enough to implement, either in
> kernelor as a LD_PRELOAD hack.

Sure, let's try it and then we will have a race.  I would be happy to
lose that race, but... let's just see who wins.

> So... untar with    sync is fair benchmark against ramback on UPS power
> and   untar without sync is fair benchmark against ramback on AC power.
> 
> But you did untar with sync                against ramback on AC power.
> 
> That's wrong.

It is consistent and correct.  You need to supply the missing features
that ramback supplies before you have a filesystem-level solution.  I
really encourage you to try it, then we can compare the two approaches
with both of them fully working.

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