Re: Journaling: Surviving or allowing unclean shutdown?

[Richard B. Johnson]

On Thu, 4 Jan 2001, Mo McKinlay wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Today, David Lang ([e-mail]) wrote:
> 
>   > On Thu, 4 Jan 2001, Mo McKinlay wrote:
>   >
>   > >   > The off button need not and _does not_ remove power instantly (if at
>   > >   > all) on many appliances.
>   > >
>   > > Indeed - but unplugging your VCR from the wall won't harm it. Everyone
>   > > knows the power button on a TV/VCR/etc doesn't actually kill the power,
>   > > just reduce consumption (i.e., standby mode). But unplugging it at the
>   > > wall doesn't have any detrimental effects - doing that to a PC will.
>   >
>   > if you change that statement to "usually won't harm it" I agree with you
>   > (I have had a VCR eat a tape when this was done)
> 
> Crikey. Most people would consider that a fault in the VCR.
> 
> Just goes to show how far removed from appliances PCs currently are.
> 

A nice "brand-name" Network-centric printer (with an IP address) requires
that you "save" the parameters in NVRAM. If you pull the plug during
this operation, it comes up with its default IP and you have to do
it again. A mobile-phone that runs out of battery power will also
lose all the phone numbers you have stored, etc. The same is true
for most all embedded systems that save data.

A file-system is a bit more sophisticated. You can design it so
that no "known" corruption occurs. A simple, but not fast method
would be to never actually modify an existing file. Instead, when
an existing file is opened for write, a copy is created. All new
work is done on the copy (which is probably invisible at the time).
Once the file is closed, and all buffers written, the new file
replaces the old. This has to be done in a manner in which a
power-failure at any time will leave you with either file, but
not both. This requires a journal to show how far you've gotten
into the 'rename' operation. A corrupted journal just leaves
you with the old file. This same idea can be modularized into
file-sections that are much smaller than an entire file. In this
manner, the working file that is actually accessed will always
seem to be perfect, although your last N-seconds of updates may
have been lost to the power failure. This means that the data-base
software has to roll-back and redo the temporarily-lost updates
when it restarts. It uses the journal to accomplish this. As
N-seconds gets smaller, the overhead necessary to maintain data
consistency gets greater, so there are trade-offs.

In the case of NVRAM data, the printer software could have been
designed to survive a power failure even though a cursory look
at the way NVRAM operates may make it seem impossible. To write
NVRAM, you erase if first. If you have a power-failure at this
time, all is lost --not. You just need to erase sectors (pages),
or have two NVRAM devices. Part of the data saved, is a number
that increases during each save operation. The CPU software
gets its parameters from the latest (highest number). 

A journaling file-system also needs some number to show the
order of operations so that roll-backs and restarts work.
Unfortunately, the systems that I have seen all use time for
the number! You don't want time to reconstruct 'order'. You
need a number that represents 'order'. Time is not your friend.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.