From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755202AbaCNOLt (ORCPT <rfc822;w@1wt.eu>);
	Fri, 14 Mar 2014 10:11:49 -0400
Received: from mail-qc0-f178.google.com ([209.85.216.178]:37849 "EHLO
	mail-qc0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754536AbaCNOLr (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 14 Mar 2014 10:11:47 -0400
Date: Fri, 14 Mar 2014 10:11:43 -0400
From: Tejun Heo <tj@kernel.org>
To: Roman Peniaev <r.peniaev@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.cz>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 1/1] fs/mpage.c: forgotten WRITE_SYNC in case of data
 integrity write
Message-ID: <20140314141143.GH12613@htj.dyndns.org>
References: <1392519268-29991-1-git-send-email-r.peniaev@gmail.com>
 <20140218155945.ee2e22e07fa3b4f242b16a7f@linux-foundation.org>
 <CACZ9PQV8RsaefFAOt5b-aL33G3CiD+3+fTuW15io6u1DH3XJ6Q@mail.gmail.com>
 <CACZ9PQUKzsP4mwJSO3c=Z3W2pYr2AME-9j+1Cqg9t8a4T+uQQg@mail.gmail.com>
 <20140313200119.GB504@quack.suse.cz>
 <20140313143456.157404fd7f208638ca70e317@linux-foundation.org>
 <20140314130712.GC12613@htj.dyndns.org>
 <CACZ9PQUQX-sSNo+z0LB0Tefq9pSHFr6GjKg2tWzdAtw3OYYDsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACZ9PQUQX-sSNo+z0LB0Tefq9pSHFr6GjKg2tWzdAtw3OYYDsg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello,

On Fri, Mar 14, 2014 at 11:07:04PM +0900, Roman Peniaev wrote:
> Seems the following message should be better:
> When data inegrity operation (sync, fsync, fdatasync calls) happens
> writeback control is set to WB_SYNC_ALL.
> In that case all write requests are marked with WRITE_SYNC, but on
> mpage writeback path
> WRITE_SYNC is missed. This patch fixes this.
> 
> Is it ok, what do you think?

I think the description should make it clear that WRITE_SYNC is about
latency, not about integrity and we probably should add comments
explaining why we're using WRITE_SYNC for WB_SYNC_ALL (because there
probably is someone waiting).

> Also, could you please help me do understand how can I guarantee
> integrity in case of block device with big volatile
> cache and filesystem, which does not support REQ_FLUSH/FUA?

If a device has a volatile cache but doesn't support flush, it can't
guarantee integrity.  There's no way for its user to determine or
force whether certain data is on non-volatile media.  It's an
inherently broken device.

Thanks.

-- 
tejun