Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp3127489ybx; Sun, 3 Nov 2019 11:21:48 -0800 (PST) X-Google-Smtp-Source: APXvYqynI0NKkVQbJxDkdJ67c2UFTCtlo5AXqMF6uFMsIi5SE0ZyUZRSrET4EaqQAySPKDTy7R2F X-Received: by 2002:a17:906:9c1:: with SMTP id r1mr19826894eje.217.1572808908635; Sun, 03 Nov 2019 11:21:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572808908; cv=none; d=google.com; s=arc-20160816; b=rGcSepR8TeuIbknCTBZ0aAODxafFLFg37QxbzcAucGtUFSvf8BSFktNSwkvuoL9Esl p2yojuptbanCMYd//sj6FDavV0WAaWHW7386J4CHNUJoj5xFuETvSxAsajcxNMEyA0qB +jNIygy3n2daZNmnGNaNR5G+6j/XAXHkMJ+X1zT0+cT7laEjPyy5vRj9BT9D8mQ/F9BK 3S7u8PyEOrUvgvMBaao7ZjAXgp9Xd9NlyJTLF1bJqJc1iUtnW0ebJehnKtBJtiDDllun 8xsG1qLbT0aBigWH50Ef836598BSVyTVLxXV566eNf4NMrlZQdesNzBeR6ebV2/bgzQ9 fpkA== 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; bh=P+ZYGsDi6jzTwDrKMv3mKTP4vgG5lwo/4qzcZdpCcdc=; b=pgCnpddbx+ge+0DvURi+EkWj6crKuF0EmKb7icxsBRZQXgKZ+jFhzJLR8h4l/Rg48l /nlCWRXDH4PXHj1xNdxrPxmeG5cRXqmuNq3omJ9Yr/PIvpC+/a2o5TstJbOvPumE90+2 z+wgFmwBLtZePkuF2dKhoenuYIrFRi7vhbBvQyUnkD0je8g1zJrJJr+ZrjyGWCSFioRG OtUXzia4TwHm73RLZRbRLpwqEMiDT07m2SOVFCjuWNEJ1LGrRf+/LtgX8NPdfgLy2tIT Umt9jvS0WFB7Q8YqJnk3Dz9mI6VWrKbaBsdbQkPiFO0LIj8xQuG1XwohnbTHx5FAZPmu hUHA== ARC-Authentication-Results: i=1; mx.google.com; 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 h6si1917686edr.188.2019.11.03.11.21.23; Sun, 03 Nov 2019 11:21:48 -0800 (PST) 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; 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 S1727913AbfKCTVB (ORCPT + 99 others); Sun, 3 Nov 2019 14:21:01 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:53295 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727343AbfKCTVB (ORCPT ); Sun, 3 Nov 2019 14:21:01 -0500 Received: from callcc.thunk.org (ip-12-2-52-196.nyc.us.northamericancoax.com [196.52.2.12]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA3JKfhL016741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 3 Nov 2019 14:20:41 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 748C9420311; Sun, 3 Nov 2019 14:20:40 -0500 (EST) Date: Sun, 3 Nov 2019 14:20:40 -0500 From: "Theodore Y. Ts'o" To: Matthew Bobrowski Cc: jack@suse.cz, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, hch@infradead.org, david@fromorbit.com, darrick.wong@oracle.com Subject: Re: [PATCH v6 00/11] ext4: port direct I/O to iomap infrastructure Message-ID: <20191103192040.GA12985@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi Matthew, could you do me a favor? For the next (and hopefully final :-) spin of this patch series, could you base it on the ext4.git's master branch. Then pull in Darrick's iomap-for-next branch, and then apply your patches on top of that. I attempted to do this with the v6 patch series --- see the tt/mb-dio branch --- and I described on another e-mail thread, I appear to have screwed up that patch conflicts, since it's causing a failure with diroead-nolock using a 1k block size. Since this wasn't something that worked when you were first working on the patch set, this isn't something I'm going to consider blocking, especially since a flay test failure which happens 7% of the time, and using dioread_nolock with a sub-page blocksize isn't something that is going to be all that common (since it wasn't working at all up until now). Still, I'm hoping that either Ritesh or you can figure out how my simple-minded handling of the patch conflict between your and his patch series can be addressed properly. Thanks!! - Ted