lkml.org 
[lkml]   [2009]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/


\
 
 \ /
  Last update: 2009-03-28 17:15    [W:0.569 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site