> > That isn't anything to do with what was being proposed. *ORDERING* not
quoted text
> > flush to media.
> 
> This is where you have made a fundamental mistake in your proposal.
> Suppose you have a steady, heavy write load onto ramback.  Eventually,
> the entire ramdisk will be dirty and you have to drop back to disk
> speed, right?  My design does not suffer from that problem, but your
> proposal does.

In your design the entire ramdisk goes bang and disappears on a crash.

quoted text
> It gets worse than that.  Suppose somebody writes the same region
> twice, how do you order that?  Do you try to store that new data
> somewhere, keeping in mind that we are already at terabyte scale?  Is
> there a limit on how much overwrite data you may have to store?  (No.)

You only have to care about ordering if there is a store barrier between
the two (not usual). You only have to care about filling if you generate
enough dirty blocks at a very high rate (which is unusual for most
workloads). If you don't care about those then we have ramdisk already and
if you want to write a ramdisk driver for external ramdisk great. You'd
also fix the layering violations then by allowing device mapper to
implement things like snapshotting and writeback seperated from your
driver.

Even in the extreme case that you propose there are trivial ways of
getting coherency. Simple example - if you can sweep all the data out in
say 10 minutes then you can buy twice the physical media and ensure that
one of the two sets of disk backups is genuinely store barrier consistent
to some snapshot time (say every 30 minutes but obviously user tunable).
If you at least had some kind of credible snapshotting you'd find people
less hostile to your glorified ramdisk.

quoted text
> > You have no guarantee of commit to stable storage so your use of the word
> > "transaction" is a bit farcical.
> 
> The UPS provides a guarantee of commit to stable storage.  No amount of

Stable storage to most people means "won't go away on a bad happening".
Transaction likewise has a specific meaning in terms of an event occuring
once only an either being recorded before or after the transaction
occurred.

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/