> > Nice fiction - stuff crashes eventually - not that this isn't useful. For
quoted text
> > 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.

quoted text
> > 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.

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

True but its a lot simpler.

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

DMA ?

quoted text
> > 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.
quoted text
> 
> > >  * 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

quoted text
> 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.

quoted text
> 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.

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/