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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.2.00.0908310847530.6822@asgard.lang.hm>
Date:	Mon, 31 Aug 2009 08:50:53 -0700 (PDT)
From:	david@...g.hm
To:	Ric Wheeler <rwheeler@...hat.com>
cc:	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, 31 Aug 2009, Ric Wheeler wrote:

> On 08/31/2009 09:16 AM, Christoph Hellwig wrote:
>> On Mon, Aug 31, 2009 at 09:15:27AM -0400, Ric Wheeler wrote:
>>>> While most common filesystem do have barrier support it is:
>>>>
>>>>    - not actually enabled for the two most common filesystems
>>>>    - the support for write barriers an cache flushing tends to be buggy
>>>>      all over our software stack,
>>>> 
>>> 
>>> Or just missing - I think that MD5/6 simply drop the requests at present.
>>> 
>>> I wonder if it would be worth having MD probe for write cache enabled&
>>> warn if barriers are not supported?
>> 
>> In my opinion even that is too weak.  We know how to control the cache
>> settings on all common disks (that is scsi and ata), so we should always
>> disable the write cache unless we know that the whole stack (filesystem,
>> raid, volume managers) supports barriers.  And even then we should make
>> sure the filesystems does actually use barriers everywhere that's needed
>> which failed at for years.
>> 
>
> I was thinking about that as well. Having us disable the write cache when we 
> know it is not supported (like in the MD5 case) would certainly be *much* 
> safer for almost everyone.
>
> We would need to have a way to override the write cache disabling for people 
> who either know that they have a non-volatile write cache (unlikely as it 
> would probably be to put MD5 on top of a hardware RAID/external array, but 
> some of the new SSD's claim to have non-volatile write cache).

I've done this when the hardware raid only suppored raid 5 but I wanted 
raid 6. I've also done it when I had enough disks to need more than one 
hardware raid card to talk to them all, but wanted one logical drive for 
the system.

> 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. 
they care about their data, but they also care about performance, and 
since performance is what they see on an ongong basis, they tend to care 
more about performance.

given that we don't even have barriers enabled by default on ext3 due to 
the performance hit, what makes you think that disabling buffers entirely 
is going to be acceptable to people?

David Lang
--
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/