Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp880850ybl; Tue, 13 Aug 2019 04:11:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqwO/thJDWvCW0Kf/dz4cKomnwHDtCC7ogmbJzRZr2k1/r42IzHpiZx6T3rt+Ip5l2bbjWM5 X-Received: by 2002:a65:5382:: with SMTP id x2mr28723441pgq.422.1565694702554; Tue, 13 Aug 2019 04:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565694702; cv=none; d=google.com; s=arc-20160816; b=kJg9dcjUXivdQmbGz0OL2ywvinfgpiGXZ2Yzq5FAuemYdC38AASJ97MJtKxVmc1iQx kFXKXwE0UwXyNg2ZjG7/OuOLCMmQq7zAUdPVbkZ0JHqZei9iXzapaaVGOqLOqSTY1KkI sKF+cBQm+P7AYn4aeZUl5uJ5zUSRhZQ71PUT73WeZhjdWFAhwc8jImBUPSA5iGjCBzpn 7UInX4OhCHTLpCpfOIySPPiXY5U2oR4ugdkK0M11YSK9pnGTkOxIhOEdwUhxcJ3vML7/ jFkvslxsE+fTwf5KZ82EeGM+m/nwMYz8BVknkyk0/NFvz2it65uQr/AIWxBd8L2XTpvY pTaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ZLqa55gYvXGeXqo1YYvYjADgFmD5JUGSVTiuNpnKm8Q=; b=A1beRPFZtxtCFJ8Y+6B5nJbR9kLmHQ6Xodq5iI+Gmbvt8t7LIiWLjlUMEmCJ/V4QjH vDNz/LkASCFfWpp9Ci3oUc++Ewe4vtoS6xVOIQPXkzdwcEgtXCYhnP7FRmRWCUZQj6s3 wj2rPhKHj6EnUi3GtkHVjZuPLurnuQh/p9XMJf0A7UBWN8iSteoTTBBmvqK2nWEH/ATK j6c8caqKZyDke7gks9BeoZfZyijUqbBaELfh28yrUu+2rWLs99DNJqbwTa8otuyiXPX/ lZz590CxmI/FaXQ+mw+mskKPlDfdzYFkkk65Ypu4DsxK/kwR1MrmypgmGxISeQocabVE oV2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mbobrowski-org.20150623.gappssmtp.com header.s=20150623 header.b=vwqt+GCy; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c18si6154759pfj.4.2019.08.13.04.11.27; Tue, 13 Aug 2019 04:11:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@mbobrowski-org.20150623.gappssmtp.com header.s=20150623 header.b=vwqt+GCy; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726789AbfHMLKN (ORCPT + 99 others); Tue, 13 Aug 2019 07:10:13 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:45502 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726721AbfHMLKN (ORCPT ); Tue, 13 Aug 2019 07:10:13 -0400 Received: by mail-pg1-f196.google.com with SMTP id o13so51073327pgp.12 for ; Tue, 13 Aug 2019 04:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mbobrowski-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZLqa55gYvXGeXqo1YYvYjADgFmD5JUGSVTiuNpnKm8Q=; b=vwqt+GCyo77O5mvVmy9w8+Udxsx4UzIxzl1IdzIdwtaMiC+HcZu9qq+55XY3a63Xli nkMMa7PYI3kBDVD+dRwZqhhuKn7IpEC72qZxUZHG/d0mmVNp7JgV4W3H3t2sAByZ/VG7 3KVZtGTiWoN1OWDC3xYAtED4aculC5vWG/O4Ci0hGMPUxICRiQyOk4ATBW2i+gaf2JWI Hz1oR2/0BWdiRqGJhclg18uv7IGNDbL38VmIlu8M40gkbvNc2fjksGAQuGM9Mp9ie6oU rQQMJWCjT1IjYc4V7PsMtKQh00A5TkOuphgb+rtWQf8+nF/VzTnjeO1RHGzzuzG78uxL Zt7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZLqa55gYvXGeXqo1YYvYjADgFmD5JUGSVTiuNpnKm8Q=; b=AARZDmaWJ73I7OxCilUVEMjveVfdPd4fkeLNVJXAzuNepC5A6UpdEvrD7Qf6rWwMeu f+MwRObzYMLL+Xv9bZp1Go9YhZzmX1eISvfTspv90hBeUdTqu+tD02HFweE15zsJkQsW AuQx5zqszIbPn8f85ymN5mR9mtWqNGoA/Ju0QkAERrP3WJtQP/mN+5vjik9I899ur0NU jTrKyxYKQjxjmPdluJ+tBLDF7gLyoKkqTgiKMf/jy22+M+OrqmUzUZm/OYbxbi1l+GYV 8EuOiYScXutaZoWIQjOwAbgmhmM7J24OuLB8kjHpikQcWMkmF3qqFyuHlcX1M3Qsn343 bQcw== X-Gm-Message-State: APjAAAUUoOxGqzY+bLPzkRueIFfazVN4J+RsJXxLBxuxEW74HYiYM9kU ratuZHglNj6mFUbLVWQG/urk X-Received: by 2002:a65:6102:: with SMTP id z2mr33855081pgu.391.1565694612705; Tue, 13 Aug 2019 04:10:12 -0700 (PDT) Received: from poseidon.bobrowski.net ([114.78.226.167]) by smtp.gmail.com with ESMTPSA id c199sm3677579pfb.28.2019.08.13.04.10.09 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 13 Aug 2019 04:10:12 -0700 (PDT) Date: Tue, 13 Aug 2019 21:10:06 +1000 From: Matthew Bobrowski To: RITESH HARJANI Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, jack@suse.cz, tytso@mit.edu Subject: Re: [PATCH 0/5] ext4: direct IO via iomap infrastructure Message-ID: <20190813111004.GA12682@poseidon.bobrowski.net> References: <20190812173150.AF04F5204F@d06av21.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190812173150.AF04F5204F@d06av21.portsmouth.uk.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, Aug 12, 2019 at 11:01:50PM +0530, RITESH HARJANI wrote: > > This patch series converts the ext4 direct IO code paths to make use of the > > iomap infrastructure and removes the old buffer_head direct-io based > > implementation. The result is that ext4 is converted to the newer framework > > and that it may _possibly_ gain a performance boost for O_SYNC | O_DIRECT IO. > > > > These changes have been tested using xfstests in both DAX and non-DAX modes > > using various configurations i.e. 4k, dioread_nolock, dax. > > I had some minor review comments posted on Patch-4. > But the rest of the patch series looks good to me. Thanks for the review, much appreciated! Also, apologies about any delayed response to your queries, I predominantly do all this work in my personal time. > I will also do some basic testing of xfstests which I did for my patches and > will revert back. Sounds good! > One query, could you please help answering below for my understanding :- > > I was under the assumption that we need to maintain > ext4_test_inode_state(inode, EXT4_STATE_DIO_UNWRITTEN) or > atomic_read(&EXT4_I(inode)->i_unwritten)) > in case of non-AIO directIO or AIO directIO case as well (when we may > allocate unwritten extents), > to protect with some kind of race with other parts of code(maybe > truncate/bufferedIO/fallocate not sure?) which may call for > ext4_can_extents_be_merged() > to check if extents can be merged or not. > > Is it not the case? > Now that directIO code has no way of specifying that this inode has > unwritten extent, will it not race with any other path, where this info was > necessary (like > in above func ext4_can_extents_be_merged())? Ah yes, I was under the same assumption when reviewing the code initially and one of my first solutions was to also use this dynamic 'state' flag in the ->end_io() handler. But, I fell flat on my face as that deemed to be problematic... This is because there can be multiple direct IOs to unwritten extents against the same inode, so you cannot possibly get away with tracking them using this single inode flag. So, hence the reason why we drop using EXT4_STATE_DIO_UNWRITTEN and use IOMAP_DIO_UNWRITTEN instead in the ->end_io() handler, which tracks whether _this_ particular IO has an underlying unwritten extent.