| Message ID | 20211210073619.21667-3-jefflexu@linux.alibaba.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fscache,erofs: fscache-based demand-read semantics | expand |
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. > 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. David
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.
diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c index 61d412580353..981e6e80690b 100644 --- a/fs/cachefiles/namei.c +++ b/fs/cachefiles/namei.c @@ -603,11 +603,17 @@ static bool cachefiles_open_file(struct cachefiles_object *object, bool cachefiles_look_up_object(struct cachefiles_object *object) { struct cachefiles_volume *volume = object->volume; - struct dentry *dentry, *fan = volume->fanout[(u8)object->cookie->key_hash]; + struct cachefiles_cache *cache = volume->cache; + struct dentry *dentry, *fan; int ret; _enter("OBJ%x,%s,", object->debug_id, object->d_name); + if (cache->mode == CACHEFILES_MODE_CACHE) + fan = volume->fanout[(u8)object->cookie->key_hash]; + else + fan = volume->dentry; + /* Look up path "cache/vol/fanout/file". */ ret = cachefiles_inject_read_error(); if (ret == 0) diff --git a/fs/cachefiles/xattr.c b/fs/cachefiles/xattr.c index 0601c46a22ef..f562dd0d4bdd 100644 --- a/fs/cachefiles/xattr.c +++ b/fs/cachefiles/xattr.c @@ -88,6 +88,7 @@ int cachefiles_set_object_xattr(struct cachefiles_object *object) */ int cachefiles_check_auxdata(struct cachefiles_object *object, struct file *file) { + struct cachefiles_cache *cache = object->volume->cache; struct cachefiles_xattr *buf; struct dentry *dentry = file->f_path.dentry; unsigned int len = object->cookie->aux_len, tlen; @@ -96,6 +97,10 @@ int cachefiles_check_auxdata(struct cachefiles_object *object, struct file *file ssize_t xlen; int ret = -ESTALE; + /* TODO: coherency check */ + if (cache->mode == CACHEFILES_MODE_DEMAND) + return 0; + tlen = sizeof(struct cachefiles_xattr) + len; buf = kmalloc(tlen, GFP_KERNEL); if (!buf)
In demand-read mode, user daemon may prepare data blob files in advance before they are lookud up. Thus simplify the logic of placing backing files, in which backing files are under "cache/<volume>/" directory directly. Also skip coherency checking currently to ease the development and debug. Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com> --- fs/cachefiles/namei.c | 8 +++++++- fs/cachefiles/xattr.c | 5 +++++ 2 files changed, 12 insertions(+), 1 deletion(-)