[PATCH 2/2] cachefiles: support query cachefiles ondemand feature
Hongbo Li
lihongbo22 at huawei.com
Thu Jun 27 22:02:10 AEST 2024
On 2024/6/24 20:58, Gao Xiang wrote:
>
>
> On 2024/6/24 19:58, Hongbo Li wrote:
>>
>>
>> On 2024/6/21 18:42, Gao Xiang wrote:
>>> Hi,
>>>
>>> On 2024/6/21 18:06, Gao Xiang wrote:
>>>>
>>>>
>>>> On 2024/6/21 17:37, Hongbo Li wrote:
>>>>>
>>>>>
>>>>> On 2024/6/21 17:14, Gao Xiang wrote:
>>>>>>
>>>>>>
>>>>>> On 2024/6/21 14:18, Hongbo Li wrote:
>>>>>>> Erofs over fscache need CONFIG_CACHEFILES_ONDEMAND in cachefiles
>>>>>>> module. We cannot know whether it is supported from userspace, so
>>>>>>> we export this feature to user by sysfs interface.
>>>>>>>
>>>>>>> [Before]
>>>>>>> $ cat /sys/fs/cachefiles/features/cachefiles_ondemand
>>>>>>> cat: /sys/fs/cachefiles/features/cachefiles_ondemand: No such
>>>>>>> file or directory
>>>>>>>
>>>>>>> [After]
>>>>>>> $ cat /sys/fs/cachefiles/features/cachefiles_ondemand
>>>>>>> supported
>>>>>>>
>>>>>>> Signed-off-by: Hongbo Li <lihongbo22 at huawei.com>
>>>>>>
>>>>>> I don't think such sysfs is needed, you could just use
>>>>>> `bind ondemand` to check if it is supported:
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/cachefiles/daemon.c?h=v6.9#n780
>>>>>>
>>>>> Thanks for reply!
>>>>> `bind ondemand` can check if it is supported, but it requires a
>>>>> more complicated procedure for user to implement. For example, a
>>>>> serial of system call (open, ioctl, close) are need.The containerd
>>>>> snapshotter daemon relies on these feature, only use a simple check
>>>>> method is usable in product environment. The snapshotter developers
>>>>> may know how cachefiles works, but for snapshotter users, a simple
>>>>> way to check whether snapshotter can be launched is useful. Even
>>>>> though they do not know how cachefiles works.
>>>>
>>>> I don't think it needs to be considered as long as userspace
>>>> has a way to check since you could wrap up these as a helper
>>>> (I will do in the official erofs-utils later or if you have
>>>> some interest you could help too) and even some erofs-utils
>>>> binary for this.
>>>>
>>>> sysfs maintainence just for some random feature doesn't
>>>> sound good to me (similar to ext4/xfs on-disk features) and
>>>> even if works, you cannot use this way for 5.19~6.10
>>>> upstream kernels.
>>>
>>> Anyway, I know userspace folks always would like to have a
>>> simple kernel way to check if a feature is supported for a
>>> kernel, but (many years later) my current thought is that
>>> the simplist way to check this is to introduce a simple
>>> helper to try. You cannot list every kernel features you
>>> concerned as some sysfs file and in time properly, or you
>>> could cause some inconsistency.
>>>
>>> Anyway, that is my personal thought, having another detailed
>>> list for all features users care about along with the real
>>> implementaions seems unnecessary.
>> Thanks for explaining!
>> Maybe the way of showing the features in erofs now seems not
>> quite reasonable. It only output the "supported" string from
>> sysfs. What suggestions do you have for this?
>
> As I said, just using "bind ondemand" and "mount fsid" to check
> if erofs over fscache is supported is enough.
>
> If userspace folks don't like the internals, these logic could
> be wrapped up in erofs-utils or whatever libraries.
>
ok, thank you!
> Thanks,
> Gao Xiang
>
>>
>> Thanks,
>> Hongbo
>>>
>>> Thanks,
>>> Gao Xiang
More information about the Linux-erofs
mailing list