linux-kernel - Re: [QUESTION] cachefiles: Recovery concerns with on-demand loading after unexpected power loss

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f177a0e4-c2da-40b7-9d47-8968f3c2bc50@huaweicloud.com>
Date: Wed, 28 May 2025 16:53:06 +0800
From: Zizhi Wo <wozizhi@...weicloud.com>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>,
 Zizhi Wo <wozizhi@...weicloud.com>, netfs@...ts.linux.dev,
 dhowells@...hat.com, jlayton@...nel.org, brauner@...nel.org
Cc: jefflexu@...ux.alibaba.com, zhujia.zj@...edance.com,
 linux-erofs@...ts.ozlabs.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, libaokun1@...wei.com, yangerkun@...wei.com,
 houtao1@...wei.com, yukuai3@...wei.com
Subject: Re: [QUESTION] cachefiles: Recovery concerns with on-demand loading
 after unexpected power loss



在 2025/5/28 16:35, Gao Xiang 写道:
> Hi Zizhi,
> 
> On 2025/5/28 16:07, Zizhi Wo wrote:
>> Currently, in on-demand loading mode, cachefiles first calls
>> cachefiles_create_tmpfile() to generate a tmpfile, and only during the 
>> exit
>> process does it call 
>> cachefiles_commit_object->cachefiles_commit_tmpfile to
>> create the actual dentry and making it visible to users.
>>
>> If the cache write is interrupted unexpectedly (e.g., by system crash or
>> power loss), during the next startup process, cachefiles_look_up_object()
>> will determine that no corresponding dentry has been generated and will
>> recreate the tmpfile and pull the complete data again!
>>
>> The current implementation mechanism appears to provide per-file 
>> atomicity.
>> For scenarios involving large image files (where significant amount of
>> cache data needs to be written), this re-pulling process after an
>> interruption seems considerable overhead?
>>
>> In previous kernel versions, cache dentry were generated during the
>> LOOK_UP_OBJECT process of the object state machine. Even if power was 
>> lost
>> midway, the next startup process could continue pulling data based on the
>> previously downloaded cache data on disk.
>>
>> What would be the recommended way to handle this situation? Or am I
>> thinking about this incorrectly? Would appreciate any feedback and 
>> guidance
>> from the community.
> 
> As you can see, EROFS fscache feature was marked as deprecated
> since per-content hooks already support the same use case.
> 
> the EROFS fscache support will be removed after I make
> per-content hooks work in erofs-utils, which needs some time
> because currently I don't have enough time to work on the
> community stuff.
> 
> Thanks,
> Gao Xiang

Thanks for your reply.

Indeed, the subsequent implementations have moved to using fanotify.
Moreover, based on evaluation, this approach could indeed lead to
performance improvements.

However, in our current use case, we are still working with a kernel
version that only supports the fscache-based approach, so this issue
still exists for us. :(

Thanks,
Zizhi Wo

> 
>>
>> Thanks,
>> Zizhi Wo
>