[Tux3] forward logging and NVRAM
Maciej Żenczykowski
zenczykowski at gmail.com
Tue Jul 29 11:06:07 PDT 2008
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
>
> _______________________________________________
> Tux3 mailing list
> Tux3 at tux3.org
> http://tux3.org/cgi-bin/mailman/listinfo/tux3
>
More information about the Tux3
mailing list