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.029 / U:0.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site