From: JeffleXu <jefflexu@linux.alibaba.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-cachefs@redhat.com, xiang@kernel.org, chao@kernel.org,
linux-erofs@lists.ozlabs.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: Re: [RFC 02/19] cachefiles: implement key scheme for demand-read mode
Date: Sat, 11 Dec 2021 13:32:47 +0800 [thread overview]
Message-ID: <aff937a0-b8fb-b9fc-22ef-d0099b392461@linux.alibaba.com> (raw)
In-Reply-To: <269788.1639134293@warthog.procyon.org.uk>
On 12/10/21 7:04 PM, David Howells wrote:
> Jeffle Xu <jefflexu@linux.alibaba.com> wrote:
>
>> Thus simplify the logic of placing backing files, in which backing files
>> are under "cache/<volume>/" directory directly.
>
> You then have a scalability issue on the directory inode lock - and there may
> also be limits on the capacity of a directory. The hash function is meant to
> work the same, no matter the cpu arch, so you should be able to copy that to
> userspace and derive the hash yourself.
Yes, as described in the cover letter, I plan to make the hashing
algorithm used by cachefiles built-in into our user daemon, so that the
user daemon could place the blob file on the right place. Then the core
logic of cachefiles won't be touched as much as possible.
>
>> Also skip coherency checking currently to ease the development and debug.
>
> Better if you can do that in erofs rather than cachefiles. Just set your
> coherency data to all zeros or something.
>
Yes it is preferred to keep the general part of cachefiles untouched.
Later we can set "CacheFiles.cache" xattr on blob files in advance to
pass this check.
--
Thanks,
Jeffle
next prev parent reply other threads:[~2021-12-11 5:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 7:36 [RFC 00/19] fscache,erofs: fscache-based demand-read semantics Jeffle Xu
2021-12-10 7:36 ` [RFC 01/19] cachefiles: add mode command Jeffle Xu
2021-12-10 7:36 ` [RFC 02/19] cachefiles: implement key scheme for demand-read mode Jeffle Xu
2021-12-10 7:36 ` [RFC 03/19] cachefiles: refactor cachefiles_adjust_size() Jeffle Xu
2021-12-10 7:36 ` [RFC 04/19] netfs: make ops->init_rreq() optional Jeffle Xu
2021-12-10 7:36 ` [RFC 05/19] netfs: refactor netfs_alloc_read_request Jeffle Xu
2021-12-10 7:36 ` [RFC 06/19] netfs: add type field to struct netfs_read_request Jeffle Xu
2021-12-10 7:36 ` [RFC 07/19] netfs: add netfs_readpage_demand() Jeffle Xu
2021-12-10 7:36 ` [RFC 08/19] netfs: refactor netfs_clear_unread() Jeffle Xu
2021-12-10 7:36 ` [RFC 09/19] netfs: refactor netfs_rreq_unlock() Jeffle Xu
2021-12-10 7:36 ` [RFC 10/19] netfs: refactor netfs_rreq_prepare_read Jeffle Xu
2021-12-10 7:36 ` [RFC 11/19] cachefiles: refactor cachefiles_prepare_read Jeffle Xu
2021-12-10 7:36 ` [RFC 12/19] erofs: export erofs_map_blocks Jeffle Xu
2021-12-10 7:36 ` [RFC 13/19] erofs: add bootstrap_path mount option Jeffle Xu
2021-12-10 7:36 ` [RFC 14/19] erofs: introduce fscache support Jeffle Xu
2021-12-10 7:36 ` [RFC 15/19] erofs: implement fscache-based metadata read Jeffle Xu
2021-12-10 7:36 ` [RFC 16/19] erofs: implement fscache-based data read Jeffle Xu
2021-12-10 7:36 ` [RFC 17/19] netfs: support on demand read Jeffle Xu
2021-12-10 7:36 ` [RFC 18/19] cachefiles: " Jeffle Xu
2021-12-10 7:36 ` [RFC 19/19] erofs: " Jeffle Xu
2021-12-10 11:04 ` [RFC 02/19] cachefiles: implement key scheme for demand-read mode David Howells
2021-12-11 5:32 ` JeffleXu [this message]
2021-12-10 11:05 ` [RFC 01/19] cachefiles: add mode command David Howells
2021-12-11 5:23 ` JeffleXu
2021-12-10 15:41 ` [RFC 09/19] netfs: refactor netfs_rreq_unlock() David Howells
2021-12-11 5:23 ` JeffleXu
2021-12-11 5:44 ` [Linux-cachefs] " JeffleXu
2021-12-11 6:57 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aff937a0-b8fb-b9fc-22ef-d0099b392461@linux.alibaba.com \
--to=jefflexu@linux.alibaba.com \
--cc=bo.liu@linux.alibaba.com \
--cc=chao@kernel.org \
--cc=dhowells@redhat.com \
--cc=eguan@linux.alibaba.com \
--cc=gerry@linux.alibaba.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tao.peng@linux.alibaba.com \
--cc=xiang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).