Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1788634pxb; Wed, 9 Feb 2022 04:39:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJzv+NtTq/OK0st5TBc93/zseC8MJREdFrBFwEfcTux8Kj9Oa2k5QW0eodivvPhn+jqPgG8y X-Received: by 2002:a17:902:6b8c:: with SMTP id p12mr2186353plk.51.1644410340608; Wed, 09 Feb 2022 04:39:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644410340; cv=none; d=google.com; s=arc-20160816; b=QsqeytrEbHx2Ndexv/eIAXbd61ytYkxStC4SCsRtPQ6VagQQpwv3OoBoQ1Y5U0PmNx fCay6wD5d2/jngT7wu/Jy02xg4FuDh+qQUxOoxeoSMNUbLwUES9o5EW95QFADj90Qbmq 3wX6uxsAYCEs9xiKhqYd7z3ymw+EjcsAlqlzK3HwIAeU5KS1Dj7av3uXkafSt+itVzFh QCcobNR7SrnxFiTanQnGvF58XMmgBI7h6xMnRLBn5KErpp5LOHjkc6kAfTqZaJaIiU2c IaD1PDaMcAdnil/zBvXa87WM1WDaAS1BzNyiAII9LhjOa83MzsZfOIlLiBEu0cIv1hha vJxA== 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=JWgB5/kxayVtzNC79JiuIsfBXkQuTAf0QkKm5lDZwpw=; b=PAV9npf0CW/AMLZO7ptSba3Q6SDUX7+rteRy6mkRzdblpQnTe7FgwiPNJCJr7ptW0z apFIozDhLeRXdAtoJ3mUj7Op5LHhXqlDxU64v+cTTTvQyN0zwAdNebHt4DyMg6XU0bE7 fbZJT/9YqyXpRJZAZ/FelJUB4Lvjkgh/kHtSJ+z34P8ECpXcuLZ+FoBXeVzYueCZMY1T BWhKHkgM1fowmC/7uyb9JfcNFKGw5CEuZkb5XW/6DZtw+HWxh+7pk1+lQ9CZ03UbidY3 coOYc1IO/MvSusQbXELXbQ9T9hPQjHY4DgcKCTseUCwEdHQ3rgrSFFO/iFtXH2RkstN5 xYXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id m7si17678957pgv.17.2022.02.09.04.39.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 04:39:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 A0AD3E143AB7; Wed, 9 Feb 2022 02:24:45 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234946AbiBIGCw (ORCPT + 99 others); Wed, 9 Feb 2022 01:02:52 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:51868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234305AbiBIGBM (ORCPT ); Wed, 9 Feb 2022 01:01:12 -0500 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DFE1C050CC3; Tue, 8 Feb 2022 22:01:14 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=15;SR=0;TI=SMTPD_---0V3zaQQi_1644386471; Received: from localhost(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0V3zaQQi_1644386471) by smtp.aliyun-inc.com(127.0.0.1); Wed, 09 Feb 2022 14:01:11 +0800 From: Jeffle Xu To: dhowells@redhat.com, linux-cachefs@redhat.com, xiang@kernel.org, chao@kernel.org, linux-erofs@lists.ozlabs.org Cc: 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: [PATCH v3 02/22] fscache: add a method to support on-demand read semantics Date: Wed, 9 Feb 2022 14:00:48 +0800 Message-Id: <20220209060108.43051-3-jefflexu@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20220209060108.43051-1-jefflexu@linux.alibaba.com> References: <20220209060108.43051-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 | 18 +++++++++++++++ include/linux/fscache.h | 25 +++++++++++++++++++++ include/linux/netfs.h | 4 ++++ 3 files changed, 47 insertions(+) diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 4f373a8ec47b..e544d6688100 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,22 @@ 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 make cache prepare for the 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 somehow prepare for + the data in the region specified by @start_pos/@len of the cache file. It may + get blocked until the backend has prepared the data in the cache file + successfully, or error encountered. + + Once it returns with 0, it is guaranteed that the requested data has been + ready in the cache file. In this case, users can retry to read from the cache + file. + + 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..efcd5d5c6726 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 - Make cache prepare for the 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 somehow prepare for the data in the file offset range specified + * by @start_pos/@len of the cache file. It may get blocked until the backend + * has prepared the data in the cache file successfully, or error encountered. + * + * 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..81fe707ad38d 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); + + /* Make cache prepare for the data */ + int (*ondemand_read)(struct netfs_cache_resources *cres, + loff_t start_pos, size_t len); }; struct readahead_control; -- 2.27.0