lkml.org 
[lkml]   [2009]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.29
Mark Lord wrote:
> Ric Wheeler wrote:
>> Mark Lord wrote:
>>> Ric Wheeler wrote:
> ..
>>> The kernel can crash, and the drives, in practice, will still
>>> flush their caches to media by themselves. Within a second or two.
>>
>> Even with desktops, I am not positive that the drive write cache
>> survives a kernel crash without data loss. If I remember correctly,
>> Chris's tests used crashes (not power outages) to display the data
>> corruption that happened without barriers being enabled properly.
> ..
>
> Linux f/s barriers != drive write caches.
>
> Drive write caches are an almost total non-issue for desktop users,
> except on the (very rare) event of a total, sudden power failure
> during extended write outs.
>
> Very rare. Yes, a huge problem for server farms. No question.
> But the majority of Linux systems are probably (still) desktops/notebooks.
>
> Cheers

I am confused as to why you think that barriers (flush barriers specifically)
are not equivalent to drive write cache. We disable barriers when the write
cache is off, use them only to insure that our ordering for fs transactions
survives any power loss. No one should be enabling barriers on linux file
systems if your write cache is disabled or if you have a battery backed write
cache (say on an enterprise class disk array).

Chris' test of barriers (with write cache enabled) did show for desktop class
boxes that you would get file system corruption (i.e., need to fsck the disk) a
huge percentage of the time.

Sudden power failures are not rare for desktops in my personal experience, I see
them several times a year in New England both at home (ice, tree limbs, etc) or
at work (unplanned outages for repair, broken AC, etc).

Ric



\
 
 \ /
  Last update: 2009-03-30 17:05    [W:0.607 / U:0.460 seconds]
©2003-2014 Jasper Spaans. Advertise on this site