cachefiles: notify the user daemon when looking up cookie
Fscache/CacheFiles used to serve as a local cache for a remote
networking fs. A new on-demand read mode will be introduced for
CacheFiles, which can boost the scenario where on-demand read semantics
are needed, e.g. container image distribution.
The essential difference between these two modes is seen when a cache
miss occurs: In the original mode, the netfs will fetch the data from
the remote server and then write it to the cache file; in on-demand
read mode, fetching the data and writing it into the cache is delegated
to a user daemon.
As the first step, notify the user daemon when looking up cookie. In
this case, an anonymous fd is sent to the user daemon, through which the
user daemon can write the fetched data to the cache file. Since the user
daemon may move the anonymous fd around, e.g. through dup(), an object
ID uniquely identifying the cache file is also attached.
Also add one advisory flag (FSCACHE_ADV_WANT_CACHE_SIZE) suggesting that
the cache file size shall be retrieved at runtime. This helps the
scenario where one cache file contains multiple netfs files, e.g. for
the purpose of deduplication. In this case, netfs itself has no idea the
size of the cache file, whilst the user daemon should give the hint on
it.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220509074028.74954-3-jefflexu@linux.alibaba.com
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2022-04-25 20:21:24 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
|
|
|
|
#ifndef _LINUX_CACHEFILES_H
|
|
|
|
#define _LINUX_CACHEFILES_H
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
2022-04-25 20:21:27 +08:00
|
|
|
#include <linux/ioctl.h>
|
cachefiles: notify the user daemon when looking up cookie
Fscache/CacheFiles used to serve as a local cache for a remote
networking fs. A new on-demand read mode will be introduced for
CacheFiles, which can boost the scenario where on-demand read semantics
are needed, e.g. container image distribution.
The essential difference between these two modes is seen when a cache
miss occurs: In the original mode, the netfs will fetch the data from
the remote server and then write it to the cache file; in on-demand
read mode, fetching the data and writing it into the cache is delegated
to a user daemon.
As the first step, notify the user daemon when looking up cookie. In
this case, an anonymous fd is sent to the user daemon, through which the
user daemon can write the fetched data to the cache file. Since the user
daemon may move the anonymous fd around, e.g. through dup(), an object
ID uniquely identifying the cache file is also attached.
Also add one advisory flag (FSCACHE_ADV_WANT_CACHE_SIZE) suggesting that
the cache file size shall be retrieved at runtime. This helps the
scenario where one cache file contains multiple netfs files, e.g. for
the purpose of deduplication. In this case, netfs itself has no idea the
size of the cache file, whilst the user daemon should give the hint on
it.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220509074028.74954-3-jefflexu@linux.alibaba.com
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2022-04-25 20:21:24 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Fscache ensures that the maximum length of cookie key is 255. The volume key
|
|
|
|
* is controlled by netfs, and generally no bigger than 255.
|
|
|
|
*/
|
|
|
|
#define CACHEFILES_MSG_MAX_SIZE 1024
|
|
|
|
|
|
|
|
enum cachefiles_opcode {
|
|
|
|
CACHEFILES_OP_OPEN,
|
2022-04-25 20:21:26 +08:00
|
|
|
CACHEFILES_OP_CLOSE,
|
2022-04-25 20:21:27 +08:00
|
|
|
CACHEFILES_OP_READ,
|
cachefiles: notify the user daemon when looking up cookie
Fscache/CacheFiles used to serve as a local cache for a remote
networking fs. A new on-demand read mode will be introduced for
CacheFiles, which can boost the scenario where on-demand read semantics
are needed, e.g. container image distribution.
The essential difference between these two modes is seen when a cache
miss occurs: In the original mode, the netfs will fetch the data from
the remote server and then write it to the cache file; in on-demand
read mode, fetching the data and writing it into the cache is delegated
to a user daemon.
As the first step, notify the user daemon when looking up cookie. In
this case, an anonymous fd is sent to the user daemon, through which the
user daemon can write the fetched data to the cache file. Since the user
daemon may move the anonymous fd around, e.g. through dup(), an object
ID uniquely identifying the cache file is also attached.
Also add one advisory flag (FSCACHE_ADV_WANT_CACHE_SIZE) suggesting that
the cache file size shall be retrieved at runtime. This helps the
scenario where one cache file contains multiple netfs files, e.g. for
the purpose of deduplication. In this case, netfs itself has no idea the
size of the cache file, whilst the user daemon should give the hint on
it.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220509074028.74954-3-jefflexu@linux.alibaba.com
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2022-04-25 20:21:24 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Message Header
|
|
|
|
*
|
|
|
|
* @msg_id a unique ID identifying this message
|
|
|
|
* @opcode message type, CACHEFILE_OP_*
|
|
|
|
* @len message length, including message header and following data
|
|
|
|
* @object_id a unique ID identifying a cache file
|
|
|
|
* @data message type specific payload
|
|
|
|
*/
|
|
|
|
struct cachefiles_msg {
|
|
|
|
__u32 msg_id;
|
|
|
|
__u32 opcode;
|
|
|
|
__u32 len;
|
|
|
|
__u32 object_id;
|
|
|
|
__u8 data[];
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* @data contains the volume_key followed directly by the cookie_key. volume_key
|
|
|
|
* is a NUL-terminated string; @volume_key_size indicates the size of the volume
|
|
|
|
* key in bytes. cookie_key is binary data, which is netfs specific;
|
|
|
|
* @cookie_key_size indicates the size of the cookie key in bytes.
|
|
|
|
*
|
|
|
|
* @fd identifies an anon_fd referring to the cache file.
|
|
|
|
*/
|
|
|
|
struct cachefiles_open {
|
|
|
|
__u32 volume_key_size;
|
|
|
|
__u32 cookie_key_size;
|
|
|
|
__u32 fd;
|
|
|
|
__u32 flags;
|
|
|
|
__u8 data[];
|
|
|
|
};
|
|
|
|
|
2022-04-25 20:21:27 +08:00
|
|
|
/*
|
|
|
|
* @off indicates the starting offset of the requested file range
|
|
|
|
* @len indicates the length of the requested file range
|
|
|
|
*/
|
|
|
|
struct cachefiles_read {
|
|
|
|
__u64 off;
|
|
|
|
__u64 len;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reply for READ request
|
|
|
|
* @arg for this ioctl is the @id field of READ request.
|
|
|
|
*/
|
|
|
|
#define CACHEFILES_IOC_READ_COMPLETE _IOW(0x98, 1, int)
|
|
|
|
|
cachefiles: notify the user daemon when looking up cookie
Fscache/CacheFiles used to serve as a local cache for a remote
networking fs. A new on-demand read mode will be introduced for
CacheFiles, which can boost the scenario where on-demand read semantics
are needed, e.g. container image distribution.
The essential difference between these two modes is seen when a cache
miss occurs: In the original mode, the netfs will fetch the data from
the remote server and then write it to the cache file; in on-demand
read mode, fetching the data and writing it into the cache is delegated
to a user daemon.
As the first step, notify the user daemon when looking up cookie. In
this case, an anonymous fd is sent to the user daemon, through which the
user daemon can write the fetched data to the cache file. Since the user
daemon may move the anonymous fd around, e.g. through dup(), an object
ID uniquely identifying the cache file is also attached.
Also add one advisory flag (FSCACHE_ADV_WANT_CACHE_SIZE) suggesting that
the cache file size shall be retrieved at runtime. This helps the
scenario where one cache file contains multiple netfs files, e.g. for
the purpose of deduplication. In this case, netfs itself has no idea the
size of the cache file, whilst the user daemon should give the hint on
it.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220509074028.74954-3-jefflexu@linux.alibaba.com
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2022-04-25 20:21:24 +08:00
|
|
|
#endif
|