Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp6990479rwb; Wed, 18 Jan 2023 11:59:43 -0800 (PST) X-Google-Smtp-Source: AMrXdXtS0DklZgbQZnNuzE1xnOx+zWIb9tMKGzSfkvfba1OX+QQ/hdUISihTihaxwWzXzMbmz9ee X-Received: by 2002:aa7:90d7:0:b0:573:487d:e852 with SMTP id k23-20020aa790d7000000b00573487de852mr7383650pfk.4.1674071983436; Wed, 18 Jan 2023 11:59:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674071983; cv=none; d=google.com; s=arc-20160816; b=S4H9rRZYpmLNLbPuA4LsjnFtlupnXC7eudbRMVosAruNFfflBpmhMtupkdMSVxy2et CMAVDhBwibID+S4i2s2zpdpgG6OLKY0sOczq8+YILDnlZviR6IkqBf8pYrKCnPYEidv+ DNH/a7UYbY9KiE3GKc+RxkTI0C0slsWMskU2GFHwac8k/y/eaZM0DoisS4qZQjhaslIq x+9wxkLpRy5h48RQjU3MBLOd2q5E161P3b/sBylwwIva+iM5PPSGwsXju4LE3GFxMh4i 7rjEgL5J9jP4FY9cgidO03qKpDYGK7g2VD5sQEaEq6BBPRlzZ26F1ugxGqa2HvlbNqiE SrUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=jE7UUdy8PLtXYkvU/lzVvfasVo94/Kknt5WCrMd4jf8=; b=gWmza7KK4bRvF/VCB77kim3ZBQsv8oVx/40NQm3+ZKYBOkuk4oYTiZHNTFA39VCUkd 6J6uMV/8qlqxXrNQCurQ5Qj8rXUMxyv6HSEsZgzuD2VDV25N7ZUN69hrJv32MnoFdLtv VYwE5UzRIONW3arABxgvMe5889q47fcaRAa/XsU7SvbHgo9HKmZDyRx3u5OkGciyWd41 SZwutfQcy937aZD78m4vR1zRZWTOtSa1MaNtTFKCeGHtEi3iZK97VuYUg5+wfGNxGnBc 0ZBnCoOwEtDKgqQZFgiHLnzpUsipQq7f7yNHDT4mVFjIjH6l1qDuzFA8B5BrydPQ/lbc kQBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=VcasuukN; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b22-20020a056a000a9600b0057509d0411esi38360825pfl.192.2023.01.18.11.59.27; Wed, 18 Jan 2023 11:59:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=VcasuukN; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229654AbjART5i (ORCPT + 99 others); Wed, 18 Jan 2023 14:57:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229512AbjART5h (ORCPT ); Wed, 18 Jan 2023 14:57:37 -0500 Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C40853E7B; Wed, 18 Jan 2023 11:57:36 -0800 (PST) Received: by mail-qv1-xf30.google.com with SMTP id p96so12425554qvp.13; Wed, 18 Jan 2023 11:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jE7UUdy8PLtXYkvU/lzVvfasVo94/Kknt5WCrMd4jf8=; b=VcasuukNdtEloIk0KqvSta3EYTM8ZwqsTHtT/bj3ut3YYOeIS/OpCCwYsncX9MgQRw QWEoc9qVZ/F1XkKxrm0SezpXexHkMc2IoDHgj92Ev1dgX/+qT8dUCDddKGE3/h3H5PaG /dX/RwGKN0ssytQHtibN5gCczlEAFvoMYwmHJOqPvhB8Thwnd49IasG9B6MiWiYHTkjO E47xpO/Rg1kdUQ3y4gHWLCdjC/BUwgQfQpzbXhSUl1R2fScq70HsoJL64sgpxVBMurGC vUTlgCtmcTRnCy8d+lhL3ei1HpMNpreExkujXFgWArIfQ3+tzbwH9lsOVRX3jBA324Bj lVPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jE7UUdy8PLtXYkvU/lzVvfasVo94/Kknt5WCrMd4jf8=; b=D83IBz0bwpDMCxSy3os6l2GZPH7bVib+14kZ/mUQKdlc4fCe070PuCgQmStoJcmM/I HOx+XxmVmdAOoznnKRfQ58cfoBaSaMeXoUelesMLgjkqHsj6s0q/ngjZYW4sA0iXmfHw L45Do2IQib7kxq1agY04kGl0Hf0e5Bbt0Ew0Jj5QGMR4asJ8qN/pDVIxm5N/vt8vFBY+ SboUAcTvqO0qwoaQjum03RWWO5QirC+gTRw6IcQH1G1vso7WzgQzF13DfqxpCxT2imBJ XRnVRMndLb09sY+Otsrbj6ThM0jqff2BhVWLHm3g1xfAAMhEXx6o/l7FX5ffC7WgRZCb KHcA== X-Gm-Message-State: AFqh2ko3yo+3mOjowHHuyHcU8wKkDgx3mzoe+eZ0ixop0pMfkR7pX7wL DQcTwe1ZRlpFNCwK1F5nwh2sMuaaP5OHz11gYXU= X-Received: by 2002:a05:6214:5e05:b0:534:b3ca:8638 with SMTP id li5-20020a0562145e0500b00534b3ca8638mr437696qvb.19.1674071855381; Wed, 18 Jan 2023 11:57:35 -0800 (PST) MIME-Version: 1.0 References: <20230108194034.1444764-1-agruenba@redhat.com> <20230108194034.1444764-9-agruenba@redhat.com> <20230108215911.GP1971568@dread.disaster.area> <20230109225453.GQ1971568@dread.disaster.area> In-Reply-To: From: =?UTF-8?Q?Andreas_Gr=C3=BCnbacher?= Date: Wed, 18 Jan 2023 20:57:24 +0100 Message-ID: Subject: Re: [RFC v6 08/10] iomap/xfs: Eliminate the iomap_valid handler To: "Darrick J. Wong" Cc: Christoph Hellwig , Dave Chinner , Andreas Gruenbacher , Alexander Viro , Damien Le Moal , Matthew Wilcox , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Am Mi., 18. Jan. 2023 um 20:04 Uhr schrieb Darrick J. Wong : > > On Tue, Jan 17, 2023 at 11:21:38PM -0800, Christoph Hellwig wrote: > > On Sun, Jan 15, 2023 at 09:29:58AM -0800, Darrick J. Wong wrote: > > > I don't have any objections to pulling everything except patches 8 and > > > 10 for testing this week. > > > > That would be great. I now have a series to return the ERR_PTR > > from __filemap_get_folio which will cause a minor conflict, but > > I think that's easy enough for Linux to handle. > > Ok, done. > > > > > > > 1. Does zonefs need to revalidate mappings? The mappings are 1:1 so I > > > don't think it does, but OTOH zone pointer management might complicate > > > that. > > > > Adding Damien. > > > > > 2. How about porting the writeback iomap validation to use this > > > mechanism? (I suspect Dave might already be working on this...) > > > > What is "this mechanism"? Do you mean the here removed ->iomap_valid > > ? writeback calls into ->map_blocks for every block while under the > > folio lock, so the validation can (and for XFS currently is) done > > in that. Moving it out into a separate method with extra indirect > > functiona call overhead and interactions between the methods seems > > like a retrograde step to me. > > Sorry, I should've been more specific -- can xfs writeback use the > validity cookie in struct iomap and thereby get rid of struct > xfs_writepage_ctx entirely? Already asked and answered in the same thread: https://lore.kernel.org/linux-fsdevel/20230109225453.GQ1971568@dread.disaster.area/ > > > 2. Do we need to revalidate mappings for directio writes? I think the > > > answer is no (for xfs) because the ->iomap_begin call will allocate > > > whatever blocks are needed and truncate/punch/reflink block on the > > > iolock while the directio writes are pending, so you'll never end up > > > with a stale mapping. > > > > Yes. > > Er... yes as in "Yes, we *do* need to revalidate directio writes", or > "Yes, your reasoning is correct"? > > --D