From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 479CFECE58D for ; Thu, 17 Oct 2019 21:56:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 13772205F4 for ; Thu, 17 Oct 2019 21:56:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2503708AbfJQV4S (ORCPT ); Thu, 17 Oct 2019 17:56:18 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:46033 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391375AbfJQV4S (ORCPT ); Thu, 17 Oct 2019 17:56:18 -0400 Received: from dread.disaster.area (pa49-181-198-88.pa.nsw.optusnet.com.au [49.181.198.88]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id A572843F0F3; Fri, 18 Oct 2019 08:56:14 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.2) (envelope-from ) id 1iLDkj-0002Ck-BA; Fri, 18 Oct 2019 08:56:13 +1100 Date: Fri, 18 Oct 2019 08:56:13 +1100 From: Dave Chinner To: "Darrick J. Wong" Cc: Christoph Hellwig , Damien Le Moal , Andreas Gruenbacher , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Dave Chinner Subject: Re: [PATCH 01/14] iomap: iomap that extends beyond EOF should be marked dirty Message-ID: <20191017215613.GN16973@dread.disaster.area> References: <20191017175624.30305-1-hch@lst.de> <20191017175624.30305-2-hch@lst.de> <20191017183917.GL13108@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191017183917.GL13108@magnolia> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=D+Q3ErZj c=1 sm=1 tr=0 a=ocld+OpnWJCUTqzFQA3oTA==:117 a=ocld+OpnWJCUTqzFQA3oTA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=XobE76Q3jBoA:10 a=20KFwNOVAAAA:8 a=7-415B0cAAAA:8 a=ckDNvsoUsni0MSp1FtYA:9 a=CjuIK1q_8ugA:10 a=igBNqPyMv6gA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 17, 2019 at 11:39:17AM -0700, Darrick J. Wong wrote: > On Thu, Oct 17, 2019 at 07:56:11PM +0200, Christoph Hellwig wrote: > > From: Dave Chinner > > > > When doing a direct IO that spans the current EOF, and there are > > written blocks beyond EOF that extend beyond the current write, the > > only metadata update that needs to be done is a file size extension. > > > > However, we don't mark such iomaps as IOMAP_F_DIRTY to indicate that > > there is IO completion metadata updates required, and hence we may > > fail to correctly sync file size extensions made in IO completion > > when O_DSYNC writes are being used and the hardware supports FUA. > > > > Hence when setting IOMAP_F_DIRTY, we need to also take into account > > whether the iomap spans the current EOF. If it does, then we need to > > mark it dirty so that IO completion will call generic_write_sync() > > to flush the inode size update to stable storage correctly. > > > > Signed-off-by: Dave Chinner > > Signed-off-by: Christoph Hellwig > > Looks ok, but need fixes tag. Also, might it be wise to split off the > ext4 section into a separate patch so that it can be backported > separately? I 've done a bit more digging on this, and the ext4 part is not needed for DAX as IOMAP_F_DIRTY is only used in the page fault path and hence can't change the file size. As such, this only affects direct IO. Hence the ext4 hunk can be added to the ext4 iomap-dio patchset that is being developed rather than being in this patch. Fixes: 3460cac1ca76 ("iomap: Use FUA for pure data O_DSYNC DIO writes") Cheers, Dave. -- Dave Chinner david@fromorbit.com