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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 773F3C43334 for ; Fri, 1 Jul 2022 18:05:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 083BA6B0071; Fri, 1 Jul 2022 14:05:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 032E26B0073; Fri, 1 Jul 2022 14:05:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E631F6B0074; Fri, 1 Jul 2022 14:05:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D53936B0071 for ; Fri, 1 Jul 2022 14:05:30 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AC79C353ED for ; Fri, 1 Jul 2022 18:05:30 +0000 (UTC) X-FDA: 79639308420.19.0745142 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 41CDC4004D for ; Fri, 1 Jul 2022 18:05:30 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8D54061275; Fri, 1 Jul 2022 18:05:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E55ECC3411E; Fri, 1 Jul 2022 18:05:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656698729; bh=JrDwbgQPLqBXU0x6iQM3zo0gvaj26BoUCXm4R3iZmiM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OsPTJ2917NohU9KpEgqY1i6QhhISWg1eVdIegQBURR9rO4rrz2FxnAyzpbY//WvGK ZSWPHnFtFqtDEuKnIJr6D54cCgHOaI3beIXdpXY59yI8zxtoi+UCanjd8Cx/iI38GN wboEqRGyk1/VDqndiY4BthRC1rfBczyGVmA8MuDV5mV0sQAu3T0xLA3mTDYDsHckhG lJjtOXs/yK2FqfZOX7GRLAVstJSFVj4QOVWRRMcBr83ZF1KvWat24bmGA2NrZy4fXn UEGm3ZqsdZbGdZm5w19l9HsZD8WArLJSZVnJmJVWQA2hMt6B5XSv0uVsVuZK9WCHBm YvTB76bOKK6PA== Date: Fri, 1 Jul 2022 11:05:28 -0700 From: "Darrick J. Wong" To: Jens Axboe Cc: Al Viro , Stefan Roesch , io-uring@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, david@fromorbit.com, jack@suse.cz, hch@infradead.org, Christoph Hellwig Subject: Re: [PATCH v7 15/15] xfs: Add async buffered write support Message-ID: References: <20220601210141.3773402-1-shr@fb.com> <20220601210141.3773402-16-shr@fb.com> <0a75a0c4-e2e5-b403-27bc-e43872fecdc1@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656698730; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Gz3aY/3r5zLu1nOeN2r+eSDgXkhuLlwa23OWXr8JM2s=; b=aahYCEq7lUunSALB4iQ8prXjtJuESd8Ld2w5Er+feYAExW97u4+gT+TQuLteG9pE1PKHRw flu3h+awgj/i31UWMq3+LTJhLSgnXHtTNqANTO2orTzZNbd3Tp2HlSzOmQ0P3B4WSAHNlO 4bVAy0HCx5WtbDv83wROf0ZFMWHJog8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656698730; a=rsa-sha256; cv=none; b=DS5IhWto5gMOJcnzW1b3qlQ2dMtbyoy/6d7I3iMaMDEbkxIo25ge8mEnJZHx30ja4BigsB v9K9USj+R8Lt3BY8SJ1DhrUoC6YoZMsfQVcktLZ869p84IdW4Ci0795MXveZbDs6jTKZ/j bizRrEGKhI8UGc1xUWt458wEhonHnJ8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OsPTJ291; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org X-Stat-Signature: yfh458xk7os6kinghmj5gghthtgh5tcf X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OsPTJ291; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 41CDC4004D X-HE-Tag: 1656698730-191026 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jul 01, 2022 at 08:38:07AM -0600, Jens Axboe wrote: > On 7/1/22 8:30 AM, Jens Axboe wrote: > > On 7/1/22 8:19 AM, Jens Axboe wrote: > >> On 6/30/22 10:39 PM, Al Viro wrote: > >>> On Wed, Jun 01, 2022 at 02:01:41PM -0700, Stefan Roesch wrote: > >>>> This adds the async buffered write support to XFS. For async buffered > >>>> write requests, the request will return -EAGAIN if the ilock cannot be > >>>> obtained immediately. > >>> > >>> breaks generic/471... > >> > >> That test case is odd, because it makes some weird assumptions about > >> what RWF_NOWAIT means. Most notably that it makes it mean if we should > >> instantiate blocks or not. Where did those assumed semantics come from? > >> On the read side, we have clearly documented that it should "not wait > >> for data which is not immediately available". > >> > >> Now it is possible that we're returning a spurious -EAGAIN here when we > >> should not be. And that would be a bug imho. I'll dig in and see what's > >> going on. > > > > This is the timestamp update that needs doing which will now return > > -EAGAIN if IOCB_NOWAIT is set as it may block. > > > > I do wonder if we should just allow inode time updates with IOCB_NOWAIT, > > even on the io_uring side. Either that, or passed in RWF_NOWAIT > > semantics don't map completely to internal IOCB_NOWAIT semantics. At > > least in terms of what generic/471 is doing, but I'm not sure who came > > up with that and if it's established semantics or just some made up ones > > from whomever wrote that test. I don't think they make any sense, to be > > honest. > > Further support that generic/471 is just randomly made up semantics, > it needs to special case btrfs with nocow or you'd get -EAGAIN anyway > for that test. > > And it's relying on some random timing to see if this works. I really > think that test case is just hot garbage, and doesn't test anything > meaningful. I had thought that NOWAIT means "don't wait for *any*thing", which would include timestamp updates... but then I've never been all that clear on what specifically NOWAIT will and won't wait for. :/ --D > -- > Jens Axboe >