linux-kernel - Re: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090831183154.GB3620@infradead.org>
Date:	Mon, 31 Aug 2009 14:31:54 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	david@...g.hm
Cc:	Ric Wheeler <rwheeler@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Michael Tokarev <mjt@....msk.ru>, Pavel Machek <pavel@....cz>,
	Theodore Tso <tytso@....edu>, NeilBrown <neilb@...e.de>,
	Rob Landley <rob@...dley.net>, Florian Weimer <fweimer@....de>,
	Goswin von Brederlow <goswin-v-b@....de>,
	kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, mtk.manpages@...il.com,
	rdunlap@...otime.net, linux-doc@...r.kernel.org,
	linux-ext4@...r.kernel.org, corbet@....net
Subject: Re: raid is dangerous but that's secret (was Re: [patch] ext2/3:
	document conditions when reliable operation is possible)

On Mon, Aug 31, 2009 at 08:50:53AM -0700, david@...g.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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/