Messages in this thread | | | Date | Sat, 28 Mar 2009 17:08:57 +0100 | From | Stefan Richter <> | Subject | Re: Linux 2.6.29 |
| |
I wrote: >> Well, for the time being, why not base considerations for performance, >> interactivity, energy consumption, graceful restoration of application >> state etc. on the assumption that kernel crashes are suitably rare? (At >> least on systems where data loss would be of concern.)
In more general terms: If overall system reliability is known insufficient, attempt to increase reliability of lower layers first. If this approach alone would be too costly in implementation or use, then also look at how to increase reliability of upper layers too.
(Example: Running a suitably reliable kernel on a desktop for "mission-critical web browsing" is possible at low cost, at least if early decisions, e.g. for well-supported video hardware, went right.)
Mark Lord wrote: > The better solution seems to be the rather obvious one: > > the filesystem should commit data to disk before altering metadata. > > Much easier and more reliable to centralize it there, rather than > rely (falsely) upon thousands of programs each performing numerous > performance-killing fsync's. > > Cheers
Sure. I forgot: Not only the frequency of I/O disruption (e.g. due to kernel crash) factors into system reliability; the particular impact of such disruption is a factor too. (How hard is recovery? Will at least old data remain available? ...) -- Stefan Richter -=====-=-=== -=-= -==-= http://arcgraph.de/sr/
| |