[QUESTION] cachefiles: Recovery concerns with on-demand loading after unexpected power loss
Gao Xiang
hsiangkao at linux.alibaba.com
Wed May 28 18:35:26 AEST 2025
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,
> Zizhi Wo
More information about the Linux-erofs
mailing list