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 X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43028C433E3 for ; Mon, 17 Aug 2020 19:25:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 235FD2065D for ; Mon, 17 Aug 2020 19:25:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (3072-bit key) header.d=samba.org header.i=@samba.org header.b="SYqByI9p" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732046AbgHQTZU (ORCPT ); Mon, 17 Aug 2020 15:25:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42442 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732025AbgHQTZM (ORCPT ); Mon, 17 Aug 2020 15:25:12 -0400 X-Greylist: delayed 1039 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 17 Aug 2020 12:25:11 PDT Received: from hr2.samba.org (hr2.samba.org [IPv6:2a01:4f8:192:486::2:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5DD6C061389; Mon, 17 Aug 2020 12:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samba.org; s=42; h=Date:Message-ID:From:Cc:To; bh=CIJRHx355gNSCr+djNZUa3YwUOfj5baupHLNqczQwkI=; b=SYqByI9pwq1dlpVLlp3gloDq+b nCykLXBu97LNWMWl+wfkSgqjOBYcveKWR4QhzUPWTrfSf79t30xNBkfyILCdm6f/EBO3rDLFzoGmK aJ3JTx9mrmP1tBjlJFzphvk2OS8SSRWnkxuRcg4Wu5HELLq6KJYdQI22nF6MpAAlyAlZu2czMWjKE cvh/rmtRllfdBscpciPs2gIsp/7lX+nhnUFAyZlmZrsfP7PV9gl3bv1H9KQnBmD3zIEB2egK92m9S AZ8AnroaxXhfmFGvZhIkVqVl3xxSHWxROBdozzjgYL+KgniiKF0cTV8zsqAe68npX++StWb4n98II LcjxaAHuLIPRtlmrWhfNo0d84y3JyTcPHqz3IaRhDeHqSqV7T39ctR0bSyvyUqjUpkV3FNjQyeAyx sG59QyhuRi/A+tV9Tx+ZR6BZZYxZLIERCxB7WTFBsKvp3iPwoUxa0xBWYtyhhT5OSTZhCz2lw/Bfx soqBKVojTBrXhsXpzdrTzMFu; Received: from [127.0.0.2] (localhost [127.0.0.1]) by hr2.samba.org with esmtpsa (TLS1.3:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim) id 1k7kU0-0005ga-CN; Mon, 17 Aug 2020 19:07:48 +0000 Subject: Re: [GIT PULL] fscache rewrite -- please drop for now To: Jeff Layton , David Wysochanski , David Howells Cc: Steve French , Linus Torvalds , Alexander Viro , Matthew Wilcox , Christoph Hellwig , Trond Myklebust , Anna Schumaker , Eric Van Hensbergen , linux-cachefs@redhat.com, linux-afs@lists.infradead.org, linux-nfs , CIFS , ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-fsdevel , LKML References: <447452.1596109876@warthog.procyon.org.uk> <1851200.1596472222@warthog.procyon.org.uk> <667820.1597072619@warthog.procyon.org.uk> <672169.1597074488@warthog.procyon.org.uk> From: Steven French Message-ID: Date: Mon, 17 Aug 2020 14:07:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/10/20 12:06 PM, Jeff Layton wrote: > On Mon, 2020-08-10 at 12:35 -0400, David Wysochanski wrote: >> On Mon, Aug 10, 2020 at 11:48 AM David Howells wrote: >>> Steve French wrote: >>> >>>> cifs.ko also can set rsize quite small (even 1K for example, although >>>> that will be more than 10x slower than the default 4MB so hopefully no >>>> one is crazy enough to do that). >>> You can set rsize < PAGE_SIZE? >>> >>>> I can't imagine an SMB3 server negotiating an rsize or wsize smaller than >>>> 64K in today's world (and typical is 1MB to 8MB) but the user can specify a >>>> much smaller rsize on mount. If 64K is an adequate minimum, we could change >>>> the cifs mount option parsing to require a certain minimum rsize if fscache >>>> is selected. >>> I've borrowed the 256K granule size used by various AFS implementations for >>> the moment. A 512-byte xattr can thus hold a bitmap covering 1G of file >>> space. >>> >>> >> Is it possible to make the granule size configurable, then reject a >> registration if the size is too small or not a power of 2? Then a >> netfs using the API could try to set equal to rsize, and then error >> out with a message if the registration was rejected. >> > ...or maybe we should just make fscache incompatible with an > rsize that isn't an even multiple of 256k? You need to set mount options > for both, typically, so it would be fairly trivial to check this at > mount time, I'd think. Yes - if fscache is specified on mount it would be easy to round rsize up (or down), at least for cifs.ko (perhaps simply in the mount.cifs helper so a warning could be returned to the user) to whatever boundary you prefer in fscache.   The default of 4MB (or 1MB for mounts to some older servers) should be fine.  Similarly if the user requested the default but the server negotiated an unusual size, not a multiple of 256K, we could round try to round it down if possible (or fail the mount if not possible to round it down to 256K).