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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75A59C433F5 for ; Thu, 16 Dec 2021 19:46:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241007AbhLPTqk (ORCPT ); Thu, 16 Dec 2021 14:46:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229945AbhLPTqj (ORCPT ); Thu, 16 Dec 2021 14:46:39 -0500 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0415AC061574 for ; Thu, 16 Dec 2021 11:46:39 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id z29so10712167edl.7 for ; Thu, 16 Dec 2021 11:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1YEg3xCizKQigIIVaj+7NPGS0vV5YzouOWDo8EKHI8Y=; b=dGLplsJKLLH7R55fT9CGKpQ+QAOXByetGDAZO4Qe5hOY96iYDADZXPv6IaRTnkyzZU YI08eiKnx/i5FnO61PQJoSbspOCrTKasx1Wska9nu2oEvPHzOmLFcQpapSbFWwnZ/gZJ a5Drpm7Pl4iYA3ZnJI1TCTMw/SmbnFNAdcPBg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1YEg3xCizKQigIIVaj+7NPGS0vV5YzouOWDo8EKHI8Y=; b=5Hzh89k3/2XI3d6Bpc3V8OLEDCC3jtPx6EYuZMUphJmH66ffffiuLfE7cpiQwb4kBM uAQDvjV0nJe85EJ++AT8DsPVX9/MpwY5Wm5J4fSWcAlCR9GUU6F9U8/Kb4KXLfH8NWeN FTAvJ0LsrS1VqFPTgdz1/GvIAg07zRflZNMu1fPWAoKFJcjHz7l0zDPwQ5pP06+3tyre rIDwx/vIZtW3VvbiurCyIQRuYVXD/l2WD3ig6uz/WlmAjjZ63VJugfRn/INKAwWKpEXs tdPX3Pzstt0DK7Hj7UMB9sotgcED8lo5Cxludxbf8kUxZHqJxbXOLIz0123T6V8McTWA uroQ== X-Gm-Message-State: AOAM533LG4ZF7LIRF1j9Yw9+pudGHPtuKCU2hBz4J2eESH+PPg9TI6yY Cnfc60HghzVHat2jmLdERdOaI/DHguqwVufFjaE= X-Google-Smtp-Source: ABdhPJy+7WVelO0LKmIF+OKGQ4ayenF96AnQIept0IjaVseyQWWETGy3Cw/9xwdJmmTLnL2H19CVhA== X-Received: by 2002:a17:906:6dce:: with SMTP id j14mr9097687ejt.305.1639683997240; Thu, 16 Dec 2021 11:46:37 -0800 (PST) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com. [209.85.221.51]) by smtp.gmail.com with ESMTPSA id 12sm2220164ejh.173.2021.12.16.11.46.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 11:46:35 -0800 (PST) Received: by mail-wr1-f51.google.com with SMTP id q16so5324581wrg.7 for ; Thu, 16 Dec 2021 11:46:34 -0800 (PST) X-Received: by 2002:a5d:4575:: with SMTP id a21mr10519052wrc.193.1639683994422; Thu, 16 Dec 2021 11:46:34 -0800 (PST) MIME-Version: 1.0 References: <163967073889.1823006.12237147297060239168.stgit@warthog.procyon.org.uk> <163967169723.1823006.2868573008412053995.stgit@warthog.procyon.org.uk> In-Reply-To: From: Linus Torvalds Date: Thu, 16 Dec 2021 11:46:18 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 56/68] afs: Handle len being extending over page end in write_begin/write_end To: Matthew Wilcox Cc: David Howells , linux-cachefs@redhat.com, Jeff Layton , Marc Dionne , linux-afs@lists.infradead.org, Trond Myklebust , Anna Schumaker , Steve French , Dominique Martinet , Alexander Viro , Omar Sandoval , JeffleXu , "open list:NFS, SUNRPC, AND..." , CIFS , ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-fsdevel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Dec 16, 2021 at 11:28 AM Matthew Wilcox wrote: > > Since ->write_begin is the place where we actually create folios, it > needs to know what size folio to create. Unless you'd rather we do > something to actually create the folio before calling ->write_begin? I don't think we can create a folio before that, because the filesystem may not even want a folio (think persistent memory or whatever). Honestly, I think you need to describe more what you actually want to happen. Because generic_perform_write() has already decided to use a PAGE_SIZE by the time write_begin() is called, Right now the world order is "we chunk things by PAGE_SIZE", and that's just how it is. I can see other options - like the filesystem passing in the chunk size when it calls generic_perform_write(). Or we make the rule be that ->write_begin() simply always is given the whole area, and the filesystem can decide how it wants to chunk things up, and return the size of the write chunk in the status (rather than the current "success or error"). But at no point will this *EVER* be a "afs will limit the size to the folio size" issue. Nothing like that will ever make sense. Allowing bigger chunks will not be about any fscache issues, it will be about every single filesystem that uses generic_perform_write(). So I will NAK these patches by David, because they are fundamentally wrong, whichever way we turn. Any "write in bigger chunks" patch will be something else entirely. Linus