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: <20080312131133.60e99d29@the-village.bc.nu>
Date:	Wed, 12 Mar 2008 13:11:33 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

> > Nice fiction - stuff crashes eventually - not that this isn't useful. For
> > a long time simply loading a 2-3GB Ramdisk off hard disk has been a good
> > way to build things like compile engines where loss of state is not bad.
> 
> Right, and now with ramback you will be able to preserve that state and
> have the performance too.  It is a wonderful world.

Actually no - ramback would be useless to this. You might crash and end
up with untrustworthy on disk state - not worth the risk.

> > Ext3 is only going to help you if the ramdisk writeback respects barriers
> > and ordering rules ?
> 
> I was alluding to to e2fsck's amazing repair ability, not ext3's journal.

Oh you mean "pray hard". e2fsck works well with typical disk style
failures, it is not robust against random chunks vanishing. I know this
as I've worked on and debugged a case where a raid card rebooted silently
and threw out the write back cache.

> > /bin/cp from initrd
> 
> But that does not satisfy the requirement you snipped:

True but its a lot simpler.

> More accurately: in general, cannot transfer directly.  The ramdisk may

DMA ?

> > suck all the content back in presumably a log structure is not a big
> > concern ?
> 
> Sorry, I failed to parse that.

I was suggesting that you want log structure for the writeback disk so
that you keep coherency and can recover it, an issue you seem intent on
ignoring in the interest of speed over any kind of practical usability.
> 
> > >  * Per chunk locking is not feasible for a terabyte scale ramdisk.
> > 
> > And we care  8) ?
> 
> "640K should be enough for anyone"
> 
> http://www.violin-memory.com/products/violin1010.html <- 504 GB ramdisk

Ok so almost nobody cares

> The finer the granularity the faster the ramdisk syncs to backing
> store.  The only attraction of coarse granularity I know of is

False. Disks are ops/second devices not bits/second.

> Your comment re fs chunk size reveals that I have failed to
> communicate the most basic principle of the ramback design: the
> backing store is not expected to represent a consistent filesystem

No I get that. You've ignored the fact I'm suggesting that design choice
is dumb.

> state during normal operation.  Only the ramdisk needs to maintain a
> consistent state, which I have taken care to ensure.  You just need
> to believe in your battery, Linux and the hardware it runs on.  Which
> of these do you mistrust?

In a big critical environment - all three.

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