lkml.org 
[lkml]   [2009]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible)
On Mon, 31 Aug 2009, Christoph Hellwig wrote:

> On Mon, Aug 31, 2009 at 08:50:53AM -0700, david@lang.hm wrote:
>>> It would also be very useful to have all of our top tier file systems
>>> enable barriers by default, provide consistent barrier on/off mount
>>> options and log a nice warning when not enabled....
>>
>> most people are not willing to live with unbuffered write performance.
>
> I'm not sure what you mean with unbuffered write support, the only
> common use of that term is for userspace I/O using the read/write
> sysctem calls directly in comparism to buffered I/O which uses
> the stdio library.
>
> But be ensure that the use of barriers and cache flushes in fsync does not
> completely disable caching (or "buffering"), it just does flush flushes
> the disk write cache in case we either commit a log buffer than need to
> be on disk, or performan an fsync where we really do want to have data
> on disk instead of lying to the application about the status of the
> I/O completion. Which btw could be interpreted as a violation of the
> Posix rules.

as I understood it, the proposal that I responded to was to change the
kernel to detect if barriers are enabled for the entire stack or not, and
if not disable the write caches on the drives.

there are definantly times when that is the correct thing to do, but I
am not sure that it is the correct thing to do by default.

David Lang


\
 
 \ /
  Last update: 2009-08-31 21:15    [W:0.190 / U:10.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site