Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1005046ybt; Tue, 7 Jul 2020 05:44:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjMhqT5+38Am0K18eJUx8zbkCkYR09NpaN/b4f5irwaV1eEwwTMlyVw6fRD4QpuM84bMR5 X-Received: by 2002:a05:6402:b57:: with SMTP id bx23mr58715897edb.304.1594125865513; Tue, 07 Jul 2020 05:44:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594125865; cv=none; d=google.com; s=arc-20160816; b=dLq24XBceoN/qBSgI/oY+20bKa/41HYwcCyx7gxdrnd+hVpuFB3Si1J+zAFWzh1IL6 0MFjZ+Cd3Ffl+jpbp2FaiDTboD2r/LsrtlJ1oTr9DlzWUgdIerwWtVeymmy7t3jFLI6r xmDYQiyN6My0aod9F+gNT/VkN9R0BcvURrDahe4byntvXpiD6W8YeFMsnvbmbBq3lwcd Iv8fZ5/5+0SdvrfThQ4XFn+i/+iVq+g+grZOVje6cEgRotzVRGGQfDQu117ob2UpcFzb unH4MkTs9nyyQigkwZSD1vwzPDHvMlMg/vZtTbeXTCZXgzIybIhQpWtg99iuIBnxo58e qR0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=kKBzrHeH0T8GbzhmxuUS5P2IvpIHgXckgIoBvltXdrk=; b=MajFcfeU5LL0iSTcPGYLS/j1chWawetsDnjx3Pfq7YZFt7EzatqW2AQrlNw2BhpXPD ZbLM0aU32PrCHMPjnDYK8jiwzWCH4aXxGAmA17O05fC/YA8sMvd3gHw0y160wJssfA1D 36pS8hqThTyEYR0Nk2r6IIYuga/lZwJ5OOfhlh1cjJ3lfgrvZJwLvBjLuXYuKQ3ADKfK eyXetrfngkl1Fu4B8oj+L8DUBLpv1Fsh8r0KqjFc2ZyHXtTWGei3z0Th86ncyK87npqA KbZvEq+4CBA7M/KnFH64CZcDNJ3ciO0tWXuZ8z4DaAveXFfCYsiKQV8emeOIot6AslJT VJZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g22si17095075edr.336.2020.07.07.05.43.54; Tue, 07 Jul 2020 05:44:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726900AbgGGMnu (ORCPT + 99 others); Tue, 7 Jul 2020 08:43:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:55188 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726757AbgGGMnu (ORCPT ); Tue, 7 Jul 2020 08:43:50 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 85558AAC5; Tue, 7 Jul 2020 12:43:49 +0000 (UTC) Date: Tue, 7 Jul 2020 07:43:46 -0500 From: Goldwyn Rodrigues To: Christoph Hellwig Cc: linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, fdmanana@gmail.com, dsterba@suse.cz, david@fromorbit.com, darrick.wong@oracle.com, cluster-devel@redhat.com, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: always fall back to buffered I/O after invalidation failures, was: Re: [PATCH 2/6] iomap: IOMAP_DIO_RWF_NO_STALE_PAGECACHE return if page invalidation fails Message-ID: <20200707124346.xnr5gtcysuzehejq@fiona> References: <20200629192353.20841-1-rgoldwyn@suse.de> <20200629192353.20841-3-rgoldwyn@suse.de> <20200701075310.GB29884@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200701075310.GB29884@lst.de> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 9:53 01/07, Christoph Hellwig wrote: > On Mon, Jun 29, 2020 at 02:23:49PM -0500, Goldwyn Rodrigues wrote: > > From: Goldwyn Rodrigues > > > > For direct I/O, add the flag IOMAP_DIO_RWF_NO_STALE_PAGECACHE to indicate > > that if the page invalidation fails, return back control to the > > filesystem so it may fallback to buffered mode. > > > > Reviewed-by: Darrick J. Wong > > Signed-off-by: Goldwyn Rodrigues > > I'd like to start a discussion of this shouldn't really be the > default behavior. If we have page cache that can't be invalidated it > actually makes a whole lot of sense to not do direct I/O, avoid the > warnings, etc. > > Adding all the relevant lists. Since no one responded so far, let me see if I can stir the cauldron :) What error should be returned in case of such an error? I think the userspace process must be immediately informed if it in unable to invalidate the page cache and complete the direct I/O. Currently, the iomap code treats this as a writeback error and continues with the direct I/O and the userspace process comes to know only during file closure. If such a change is incorporated, are the current userspace applications prepared for it? -- Goldwyn