Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp789586pxb; Thu, 17 Feb 2022 15:01:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJySBvsKEp73mDC4WIGsgHB0DGs6CEw7jvBAwkHZbsChCCJmkc2hV+ZuqBe5Azhbz14O1p+Z X-Received: by 2002:a17:90b:4c8e:b0:1b9:f99f:1218 with SMTP id my14-20020a17090b4c8e00b001b9f99f1218mr9665347pjb.75.1645138887002; Thu, 17 Feb 2022 15:01:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645138886; cv=none; d=google.com; s=arc-20160816; b=D9II3Aex68k6N3CW1VQ5Ir5sPx/Yc3vwlxA9v1+/HrYPR9w/qsUBfQWqR0WYTpKt1Y bPmtXmFoEoGS7f+gIKMH0yM4bpEcGFasfgjOVm7BUrUOfu2MYhH5soc3+7iqjN+AU2NB 3MXCtEsrS0+BimsC4eYHL2VgzVEgMPGxeQeieRuH0cMLL0QysOVIBK1Jlwnoh3wqVsI6 aSvUHzqLFJgO/H7CJRVpthHlytkec8dibe3qXNhKwCqWeRJn6r7bL59mr+gtPikkEP6P f0tn0M0FBX50HJ1S9GwI4VAt3BFBpHKYWA/eXJgMMakYLDwvRNH+aONLUW6BJhxpv6GR bFgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=bgVsVZOIFPFDhFVd7qL1RK7ADwFH4gGO0xurr4M8vyw=; b=E6dek9p8zhk67DD3FeAMpWqbKB0tp9sVZCxm9tHWG7QprZNXhs5d2rYNrHsgIVuO+F YzZqhkT5i00WwvK6oOzJ+suy25pE4ccfbC5/UtZkw6lwg6SITbZpjhn9h1t6k9omgRCa rYuGP8q5T47CXJ4ON/8aDDE2cc+iBFTIzAY48hqVUTuGsSCRb/n2f6+lhk2ivg6SK1c/ vAwwkl22cNCLgN94yFjEicpr3bEGEmnGmha62yjGqkoxBw9djU/cb+v9n0sxixtgmW3A q7xBtaBwbGr978hpOTtL/de2AX0WdfBX3WpJOBUPIiFEfgtOJwVAoJqQi7tvTNsEusrw um3A== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q17si16996944pla.427.2022.02.17.15.01.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Feb 2022 15:01:26 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 85A3A128DC8; Thu, 17 Feb 2022 14:57:16 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240204AbiBQMCW (ORCPT + 99 others); Thu, 17 Feb 2022 07:02:22 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:51686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240184AbiBQMCP (ORCPT ); Thu, 17 Feb 2022 07:02:15 -0500 Received: from out30-42.freemail.mail.aliyun.com (out30-42.freemail.mail.aliyun.com [115.124.30.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DCB4B60F4; Thu, 17 Feb 2022 04:02:00 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R941e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01424;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0V4keWKf_1645099317; Received: from localhost(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0V4keWKf_1645099317) by smtp.aliyun-inc.com(127.0.0.1); Thu, 17 Feb 2022 20:01:58 +0800 From: Jeffle Xu To: dhowells@redhat.com, linux-cachefs@redhat.com Cc: xiang@kernel.org, torvalds@linux-foundation.org, gregkh@linuxfoundation.org, willy@infradead.org, linux-fsdevel@vger.kernel.org, joseph.qi@linux.alibaba.com, bo.liu@linux.alibaba.com, tao.peng@linux.alibaba.com, gerry@linux.alibaba.com, eguan@linux.alibaba.com, linux-kernel@vger.kernel.org Subject: [RESEND PATCH v3 2/4] fscache: add a method to support on-demand read semantics Date: Thu, 17 Feb 2022 20:01:52 +0800 Message-Id: <20220217120154.16658-3-jefflexu@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20220217120154.16658-1-jefflexu@linux.alibaba.com> References: <20220217120154.16658-1-jefflexu@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=no 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-kernel@vger.kernel.org Add .ondemand_read() callback to netfs_cache_ops to implement on-demand read. The precondition for implementing on-demand read semantics is that, all blob files have been placed under corresponding directory with correct file size (sparse files) on the first beginning. When upper fs starts to access the blob file, it will "cache miss" (hit the hole). Then .ondemand_read() callback can be called to notify backend to prepare the data. The implementation of .ondemand_read() callback can be backend specific. The following patch will introduce the implementation for cachefiles, which will notify user daemon the requested file range to read. The .ondemand_read() callback will get blocked until the user daemon has prepared the corresponding data. Then once .ondemand_read() callback returns with 0, it is guaranteed that the requested data has been ready. In this case, users can retry to read from the backing file. Signed-off-by: Jeffle Xu --- Documentation/filesystems/netfs_library.rst | 17 ++++++++++++++ include/linux/fscache.h | 25 +++++++++++++++++++++ include/linux/netfs.h | 4 ++++ 3 files changed, 46 insertions(+) diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 4f373a8ec47b..075370d4c021 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -466,6 +466,8 @@ operation table looks like the following:: int (*query_occupancy)(struct netfs_cache_resources *cres, loff_t start, size_t len, size_t granularity, loff_t *_data_start, size_t *_data_len); + int (*ondemand_read)(struct netfs_cache_resources *cres, + loff_t start_pos, size_t len); }; With a termination handler function pointer:: @@ -552,6 +554,21 @@ The methods defined in the table are: It returns 0 if some data was found, -ENODATA if there was no usable data within the region or -ENOBUFS if there is no caching on this file. + * ``ondemand_read()`` + + [Optional] Called to prepare cache for the requested data. It shall be called + only when on-demand read semantics is required. It will be called when a cache + miss is encountered. The function will make the backend prepare the data + regarding to @start_pos/@len of the cache file. It may get blocked until the + backend finishes getting the requested data or returns errors. + + Once it returns with 0, it is guaranteed that the requested data has been + ready in the cache file. In this case, users can get the data with another + read request. + + It returns 0 if data has been ready in the cache file, or other error code + from the cache, such as -ENOMEM. + Note that these methods are passed a pointer to the cache resource structure, not the read request structure as they could be used in other situations where there isn't a read request structure as well, such as writing dirty data to the diff --git a/include/linux/fscache.h b/include/linux/fscache.h index d2430da8aa67..34af865ba928 100644 --- a/include/linux/fscache.h +++ b/include/linux/fscache.h @@ -514,6 +514,31 @@ int fscache_read(struct netfs_cache_resources *cres, term_func, term_func_priv); } +/** + * fscache_ondemand_read - Prepare cache for the requested data. + * @cres: The cache resources to use + * @start_pos: The beginning file offset in the cache file + * @len: The length of the file offset range in the cache file + * + * This shall only be called when a cache miss is encountered. It will make + * the backend prepare the data regarding to @start_pos/@len of the cache file. + * It may get blocked until the backend finishes getting the requested data or + * returns errors. + * + * Returns: + * * 0 - Success (Data is ready in the cache file) + * * Other error code from the cache, such as -ENOMEM. + */ +static inline +int fscache_ondemand_read(struct netfs_cache_resources *cres, + loff_t start_pos, size_t len) +{ + const struct netfs_cache_ops *ops = fscache_operation_valid(cres); + if (ops->ondemand_read) + return ops->ondemand_read(cres, start_pos, len); + return -EOPNOTSUPP; +} + /** * fscache_begin_write_operation - Begin a write operation for the netfs lib * @cres: The cache resources for the write being performed diff --git a/include/linux/netfs.h b/include/linux/netfs.h index 614f22213e21..3d5f0376a326 100644 --- a/include/linux/netfs.h +++ b/include/linux/netfs.h @@ -251,6 +251,10 @@ struct netfs_cache_ops { int (*query_occupancy)(struct netfs_cache_resources *cres, loff_t start, size_t len, size_t granularity, loff_t *_data_start, size_t *_data_len); + + /* Prepare cache for the requested data */ + int (*ondemand_read)(struct netfs_cache_resources *cres, + loff_t start_pos, size_t len); }; struct readahead_control; -- 2.27.0