Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5687353pxb; Thu, 20 Jan 2022 02:29:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJxxoPEqWO/n5HYzmj5NGo4yH0NdlnTNySxO1+flgw3r+eJtUbCBXoJX6t4qeVxPouCwH/Jp X-Received: by 2002:a17:90a:c583:: with SMTP id l3mr9870345pjt.197.1642674552637; Thu, 20 Jan 2022 02:29:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642674552; cv=none; d=google.com; s=arc-20160816; b=CZhUx1Xqyp8yZnMXH8eUc1H8IOr7je8LkZ3YRqG4xiD2As7ZVsMHATk1f4dZ/Uhb88 POMeSjmyLd7RlIMWWYDLmh9jKJRQ297H3JmuY3PqrqUGarv92Cjw71iPZEVojOpMZBd2 rPiWnvLnCpflwg4GCYRpFaLsDXipWy8yld9Akvu7gPvSs6LmZ/q+Zu4hBu08Xeen1wwN mQVFBuDliA5YnXRqTbwrEMiIn9YvVcYAGRHm8gy6LW3ceEXb42mpa/G0+dCbiZNci7jM EcCcw2th5zsotP8owvOKo+aw/UWfz4EOAETDP7wJUnHNijh+4+zfZ+6kMjmnYpcRDsSb EM9g== 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=Gc2vo8MEHOW11DIDReM8dOFbT34o3qr6+20gcC+sRfk=; b=RliMvQDWavIbGKs9zRJmeWfn2P6069K5+RnHGpRVm/6/jee8LRSJwSUwPDcdz4h/eT rgObFpXtT10nf+yKoY8yNog2eFx3WR/as0OWfBbO4wGg6kxY+9x+U62Om3kZnWIfWG3V VrcGmMGcdc9nS3q8ezeRKCTW0SkYRtH948NgdCQQ7y9jMDbpFzkv9+bU/g1/MLO53Z3M 52oXxneq9dO3iKa+SB0IRNbnZ91IaxAPYuPbLO4ejg1z/ZmrVVdbgLT4W6IbtGJ9txZ8 I2cV2dmGDrj+QkG2ojS6k68j8h3La6dhYyu5evs6H/JjCBFJX19kyQE23+mq69AZeTIX Tt+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mi2si218607pjb.139.2022.01.20.02.29.00; Thu, 20 Jan 2022 02:29:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242635AbiARNMn (ORCPT + 99 others); Tue, 18 Jan 2022 08:12:43 -0500 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:58583 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242171AbiARNMc (ORCPT ); Tue, 18 Jan 2022 08:12:32 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R411e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0V2C1Qxj_1642511548; Received: from localhost(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0V2C1Qxj_1642511548) by smtp.aliyun-inc.com(127.0.0.1); Tue, 18 Jan 2022 21:12:29 +0800 From: Jeffle Xu To: dhowells@redhat.com, linux-cachefs@redhat.com, xiang@kernel.org, chao@kernel.org, linux-erofs@lists.ozlabs.org Cc: 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 v2 10/20] erofs: register global fscache volume Date: Tue, 18 Jan 2022 21:12:06 +0800 Message-Id: <20220118131216.85338-11-jefflexu@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20220118131216.85338-1-jefflexu@linux.alibaba.com> References: <20220118131216.85338-1-jefflexu@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org All erofs instances will share one global fscache volume. In this using scenario, one erofs instance could be mounted from one (or multiple) blob files instead of blkdev. The number of blob files that each erofs instance could correspond to is limited, since these blob files are quite large in size. For example, when used for container image distribution, one erofs instance used for container image for node.js will correspond to ~20 blob files in total. Thus in densely employed environment, there could be as many as hundreds of containers and thus thousands of fscache cookies under one fscache volume. Then as for cachefiles backend, the hash table managing all cookies under one volume contains 32K slots. Thus the hashing functionality shall scale well in this case. Besides, cachefiles backend will scatter backing files under 256 fan sub-directoris, and thus the scalability of looking up backing files shall also not be an issue. Signed-off-by: Jeffle Xu --- fs/erofs/Makefile | 3 ++- fs/erofs/fscache.c | 21 +++++++++++++++++++++ fs/erofs/internal.h | 5 +++++ fs/erofs/super.c | 7 +++++++ 4 files changed, 35 insertions(+), 1 deletion(-) create mode 100644 fs/erofs/fscache.c diff --git a/fs/erofs/Makefile b/fs/erofs/Makefile index 8a3317e38e5a..21999e8a4728 100644 --- a/fs/erofs/Makefile +++ b/fs/erofs/Makefile @@ -1,7 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_EROFS_FS) += erofs.o -erofs-objs := super.o inode.o data.o namei.o dir.o utils.o pcpubuf.o sysfs.o +erofs-objs := super.o inode.o data.o namei.o dir.o utils.o pcpubuf.o sysfs.o \ + fscache.o erofs-$(CONFIG_EROFS_FS_XATTR) += xattr.o erofs-$(CONFIG_EROFS_FS_ZIP) += decompressor.o zmap.o zdata.o erofs-$(CONFIG_EROFS_FS_ZIP_LZMA) += decompressor_lzma.o diff --git a/fs/erofs/fscache.c b/fs/erofs/fscache.c new file mode 100644 index 000000000000..9c32f42e1056 --- /dev/null +++ b/fs/erofs/fscache.c @@ -0,0 +1,21 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Copyright (C) 2021, Alibaba Cloud + */ +#include "internal.h" + +static struct fscache_volume *volume; + +int __init erofs_init_fscache(void) +{ + volume = fscache_acquire_volume("erofs", NULL, NULL, 0); + if (!volume) + return -EINVAL; + + return 0; +} + +void erofs_exit_fscache(void) +{ + fscache_relinquish_volume(volume, NULL, false); +} diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h index 2b9337d385ce..c2608a469107 100644 --- a/fs/erofs/internal.h +++ b/fs/erofs/internal.h @@ -17,6 +17,7 @@ #include #include #include +#include #include "erofs_fs.h" /* redefine pr_fmt "erofs: " */ @@ -616,6 +617,10 @@ static inline int z_erofs_load_lzma_config(struct super_block *sb, } #endif /* !CONFIG_EROFS_FS_ZIP */ +/* fscache.c */ +int erofs_init_fscache(void); +void erofs_exit_fscache(void); + #define EFSCORRUPTED EUCLEAN /* Filesystem is corrupted */ #endif /* __EROFS_INTERNAL_H */ diff --git a/fs/erofs/super.c b/fs/erofs/super.c index 12755217631f..798f0c379e35 100644 --- a/fs/erofs/super.c +++ b/fs/erofs/super.c @@ -814,6 +814,10 @@ static int __init erofs_module_init(void) if (err) goto sysfs_err; + err = erofs_init_fscache(); + if (err) + goto fscache_err; + err = register_filesystem(&erofs_fs_type); if (err) goto fs_err; @@ -821,6 +825,8 @@ static int __init erofs_module_init(void) return 0; fs_err: + erofs_exit_fscache(); +fscache_err: erofs_exit_sysfs(); sysfs_err: z_erofs_exit_zip_subsystem(); @@ -841,6 +847,7 @@ static void __exit erofs_module_exit(void) /* Ensure all RCU free inodes / pclusters are safe to be destroyed. */ rcu_barrier(); + erofs_exit_fscache(); erofs_exit_sysfs(); z_erofs_exit_zip_subsystem(); z_erofs_lzma_exit(); -- 2.27.0