Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp8359150rwb; Wed, 23 Nov 2022 20:52:23 -0800 (PST) X-Google-Smtp-Source: AA0mqf6B+E2fLQMosJZIoHd/3bWijr7uD74IPa5M+P4NB1Frnk67X5RG4+iVFPwQwNRqmuVR7JKl X-Received: by 2002:a05:6402:24a0:b0:458:ad54:20d5 with SMTP id q32-20020a05640224a000b00458ad5420d5mr27905414eda.86.1669265543484; Wed, 23 Nov 2022 20:52:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669265543; cv=none; d=google.com; s=arc-20160816; b=JjGYkc+ado4rk4cilHH5VYWsYElt77nYXaUKgWN9KFU6eqwCUMMhu+CwhDebfT3RPg XJdMgqvaV9NzxI2PsJLY6txkka6+P0Xz2E7F4WFaSRBgGwTmOhivo9AQSbJRlqN3JpX1 V+YsyKCUbyQ9ir12tBjErfgfEIwbD74+Gc/rBHbJdS7ZyZC6tlzUrGYGeyelw24yFGl+ MbqEfXqz+ljmyNQM4SYpfA7jNs24s+Wb8s0lq0LV8sQZdjUaTPmniQD+ufKATluB7gHo QUsE58lh/2pOTho+Pi1+gT/P8n8a/vsoZH69pjgxHBH3Cg13b2mEHcWJaiMnpWSnYRKM tnug== 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 :message-id:date:subject:cc:to:from; bh=d3btORi2OSqKQ8Pk6xhmA8YC4/J/vqbEMREPyIn0+Fc=; b=u7kFsV7hBA2AH2hZiZzcNG09uZXJ7aSdZr/bEIsJPLFSxJEVO+VReK9g9EDkip1oHP VGI/rgrXRXpE0Vpafl5rRi601x4G/F/P85QTV12GbOLRcjBLBeXek5Jj4sOLSvG3ZQHo pweIiiedyYV02YL+vvcBV/g/VjLowbUdUKGz/Vcz2KLhW/0pjLKUxJ064KWRb80k4l6R hcnkymZPE7j8u5b1oxyPlRuqQTIK4BF6afJQgl5DqTmrIwqsV/CA1R87ypDUqNs/EeS5 liOnb2th33YHYmEvd2FwZHvsOs1RukwNDLwXJSE8oD4vUqcAe1K7S2NUcfSuHyskQl6C 6Idw== 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:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qb31-20020a1709077e9f00b007adb3888ad9si20228ejc.351.2022.11.23.20.52.02; Wed, 23 Nov 2022 20:52:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229688AbiKXDmT (ORCPT + 88 others); Wed, 23 Nov 2022 22:42:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229455AbiKXDmR (ORCPT ); Wed, 23 Nov 2022 22:42:17 -0500 Received: from out30-43.freemail.mail.aliyun.com (out30-43.freemail.mail.aliyun.com [115.124.30.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 799B75A6CF; Wed, 23 Nov 2022 19:42:15 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045170;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0VVZO4J._1669261332; Received: from localhost(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0VVZO4J._1669261332) by smtp.aliyun-inc.com; Thu, 24 Nov 2022 11:42:13 +0800 From: Jingbo Xu To: dhowells@redhat.com, jlayton@kernel.org, xiang@kernel.org, chao@kernel.org, linux-cachefs@redhat.com, linux-erofs@lists.ozlabs.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 0/2] fscache,cachefiles: add prepare_ondemand_read() interface Date: Thu, 24 Nov 2022 11:42:10 +0800 Message-Id: <20221124034212.81892-1-jefflexu@linux.alibaba.com> X-Mailer: git-send-email 2.19.1.6.gb485710b MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL 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-kernel@vger.kernel.org v5: - patch 1: add back netfs_inode number to trace_cachefiles_prep_read, and .prepare_ondemand_read() now also accepts a "ino_t ino" parameter (David) - add reviewed-by tags v4: https://lore.kernel.org/all/20221117053017.21074-1-jefflexu@linux.alibaba.com/ - patch 1 - make cachefiles_do_prepare_read() pass start by value (Jeff Layton) - adjust the indentation of the parameter/argument list, so that they are all lined up (David) - pass flags in for cachefiles_prepare_ondemand_read(), so that it can tail call cachefiles_do_prepare_read() directly without shuffling arguments around (David) - declare cachefiles_do_prepare_read() as inline, to eliminate one extra function calling and arguments copying when calling cachefiles_do_prepare_read() (David) v3: - rebase to v6.1-rc5, while the xas_retry() checking in patch 2 has been extracted out as a separate fix [1] [1] commit 37020bbb71d9 ("erofs: fix missing xas_retry() in fscache mode") (https://github.com/torvalds/linux/commit/37020bbb71d9) v2: - patch 1: the generic routine, i.e. cachefiles_do_prepare_read() now accepts a parameter list instead of netfs_io_subrequest, and thus some debug info retrieved from netfs_io_subrequest is removed from trace_cachefiles_prep_read(). - patch 2: add xas_retry() checking in erofs_fscache_req_complete() [Rationale] =========== Fscache has been landed as a generic caching management framework in the Linux kernel for decades. It aims to manage cache data availability or fetch data if needed. Currently it's mainly used for network fses, but in principle the main caching subsystem can be used more widely. We do really like fscache framework and we believe it'd be better to reuse such framework if possible instead of duplicating other alternatives for better maintenance and testing. Therefore for our container image use cases, we applied the existing fscache to implement on-demand read for erofs in the past months. For more details, also see [1]. In short, here each erofs filesystem is composed of multiple blobs (or devices). Each blob corresponds to one fscache cookie to strictly follow on-disk format and implement the image downloading in a deterministic manner, which means it has a unique checksum and is signed by vendors. Data of each erofs inode can be scattered among multiple blobs (cookie) since erofs supports chunk-level deduplication. In this case, each erofs inode can correspond to multiple cookies, and there's a logical to physical offset mapping between the logical offset in erofs inode and the physical offset in the backing file. As described above, per-cookie netfs model can not be used here directly. Instead, we'd like to propose/decouple a simple set of raw fscache APIs, to access cache for all fses to use. We believe it's useful since it's like the relationship between raw bio and iomap, both of which are useful for local fses. fscache_read() seems a reasonable candidate and is enough for such use case. In addition, the on-demand read feature relies on .prepare_read() to reuse the hole detecting logic as much as possible. However, after fscache/netfs rework, libnetfs is preferred to access fscache, making .prepare_read() closely coupled with libnetfs, or more precisely, netfs_io_subrequest. [What We Do] ============ As we discussed previously, we propose a new interface, i,e, .prepare_ondemand_read() dedicated for the on-demand read scenarios, which is independent on netfs_io_subrequest. The netfs will still use the original .prepare_read() as usual. Jingbo Xu (2): fscache,cachefiles: add prepare_ondemand_read() callback erofs: switch to prepare_ondemand_read() in fscache mode fs/cachefiles/io.c | 77 +++++---- fs/erofs/fscache.c | 261 +++++++++++------------------- include/linux/netfs.h | 8 + include/trace/events/cachefiles.h | 27 ++-- 4 files changed, 166 insertions(+), 207 deletions(-) -- 2.19.1.6.gb485710b