[Tux3] forward logging and NVRAM

[timothy norman huber]

Maciej,
MRAM would be suitable for this.  Freescale Semi spun off their MRAM  
unit recently, but they're shipping small (but expensive) MRAM chips.
-Timothy

> The real problem here is that this is going to be a constantly written
> 16 bytes of nvram.
> This will _very_ very quickly kill any type of flash that I'm aware
> of...  as such it would have to be something
> along the lines of a battery backed few KB of ram, with write out to
> flash on failure.
> Not sure what the lifetime in write-cycles of the standard cmos nvram
> is, but even if (being battery backed)
> it would work, that's a real hard place to find any space...?
>
> Maciej
>
> On Sun, Jul 27, 2008 at 14:29, Daniel Phillips <phillips at  
> phunq.net> wrote:
> > Hi Timothy,
> >
> > On Sunday 27 July 2008 14:10, timothy norman huber wrote:
> >> Daniel,
> >>
> >> Several weeks ago, during a discussion over coffee, you mentioned a
> >> rather intriguing optimization- by writing the start of the forward
> >> log chain to NVRAM rather than disk, you avoid a disk seek and  
> write
> >> transfer for each forward log chain.  i believe there was another
> >> motivation that had to do with avoiding traversing the entire  
> volume
> >> in case of a crash.  Was this design feature to overcome lame fsck
> >> performance?
> >
> > The same motivation, actually.  Writing the start of a forward log
> > chain to nvram instead of to some known location on disk means  
> that I
> > do not have to worry about doing unnatural things to optimize such
> > loads as O_SYNC writing, where each transaction has to complete
> > before the next one can begin, which means that the forward log  
> chain
> > never gets more than one element log, requiring a seek to the known
> > location for every transaction.  Not worse than journalling to be
> > sure, and usually better, but not as fast as avoiding a seek and  
> disk
> > write per transaction entirely.
> >
> > So if somebody could give me 16 bytes of NVRAM or so per volume I
> > would be most pleased and could use that to generate some nice  
> O_SYNC
> > benchmarks :-)
> >
> > By the way, I wonder why your posts do not show up in the Mailman
> > (Pipermail) archive, while mine and Matt's do?
> >
> > Daniel



Timothy Huber
Strategic Account Development

tim.huber at metaram.com
cell 310 795.6599

MetaRAM Inc.
181 Metro Drive, Suite 400
San Jose, CA 95110

http://www.linkedin.com/in/timhuber

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phunq.net/pipermail/tux3/attachments/20080731/fe19db47/attachment-0001.html>
-------------- next part --------------
_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3