From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mbroz@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
	by mail.saout.de (Postfix) with ESMTP
	for <dm-crypt@saout.de>; Sat, 26 Jun 2010 21:24:33 +0200 (CEST)
Received: from int-mx05.intmail.prod.int.phx2.redhat.com
	(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5QJOWQk015935
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <dm-crypt@saout.de>; Sat, 26 Jun 2010 15:24:32 -0400
Received: from [10.36.7.123] (vpn1-7-123.ams2.redhat.com [10.36.7.123])
	by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id o5QJOR9Z004584
	for <dm-crypt@saout.de>; Sat, 26 Jun 2010 15:24:31 -0400
Message-ID: <4C2653EB.2090606@redhat.com>
Date: Sat, 26 Jun 2010 21:24:27 +0200
From: Milan Broz <mbroz@redhat.com>
MIME-Version: 1.0
References: <1277553580.29791.40.camel@fermat.scientia.net>	<20100626125223.GA26185@tansi.org>	<1277562112.3245.40.camel@fermat.scientia.net>
	<20100626183632.GA30731@tansi.org>
In-Reply-To: <20100626183632.GA30731@tansi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] FYI: how to (really) cleanly shutdown
 the	system	when root is on multiple stacked block devices
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On 06/26/2010 08:36 PM, Arno Wagner wrote:
> On Sat, Jun 26, 2010 at 04:21:52PM +0200, Christoph Anton Mitterer wrote:

>> And I'm not even sure if flushing alone is enough,... or where one needs
>> something like barriers...
>
> Barriesrs are a filesystem concept and play no role here.

Nope, "IO barriers" here are block level functionality.

See Documentation/block/barrier.txt  in kernel
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/block/barrier.txt;hb=HEAD

(yes, it is confusing:-)

> Flushing ("fdatasync" or "fsunc") is not enough in some cases,
> hence the ro-remount, which is.

fsycn currently in kerenl issues barrier in block layer and then waits for it.

But if because ever reads can cause some metadata updates (last access on file stamp),
remounting read-only is there.

Milan