[lkml]   [2001]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Journaling: Surviving or allowing unclean shutdown?
> in an enbedded device you can
> 1. setup the power switch so it doesn't actually turn things off (it
> issues the shutdown command instead)

Costs too much money

> 2. run from read-only media almost exclusivly so that power event's don't
> bother you much

Depends on the device

> 3. you can add extra power inside the device so that if someone does pull
> the plug, you have a few seconds of power to do the clean shutdown

Incredibly expensive

> 4. you can run out of ram and force the user to do an extra step to save
> any changes to non-volitile storage (and if they power off during the save
> the results are undefined)

Frowned upon because you keep getting dead units back

> an improved filesystem that tolorates bad shutdowns reasonably well will
> be welcomed for other reasons, but should not be viewed as a fix for
> people pulling the plug on you.

If it doesnt fix the pulling the plug case (at least as far as 'after fsync
returned this data is safe') then its not working. A journalling file system
is always consistent. fsync/sync/msync define write barrier operations.

Applications do have to deal with more things (partial dbase write for example)
but competently written databases and transaction managers handle this.

Ext3 has been tested on the random live switchoffs on a real box because kept crashing during backups and it took us a while to figure
out that the network backup tool was backing up in /proc/bus/pci and stopping
the box dead when it backed up the pci config space of the ACPI controller.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.065 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site