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
ftp.linux.org.uk 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.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/