From: Zizhi Wo <wozizhi@huaweicloud.com>
To: netfs@lists.linux.dev, dhowells@redhat.com, jlayton@kernel.org,
brauner@kernel.org
Cc: hsiangkao@linux.alibaba.com, jefflexu@linux.alibaba.com,
zhujia.zj@bytedance.com, linux-erofs@lists.ozlabs.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
wozizhi@huawei.com, libaokun1@huawei.com, yangerkun@huawei.com,
houtao1@huawei.com, yukuai3@huawei.com
Subject: [QUESTION] cachefiles: Recovery concerns with on-demand loading after unexpected power loss
Date: Wed, 28 May 2025 16:07:59 +0800 [thread overview]
Message-ID: <20250528080759.105178-1-wozizhi@huaweicloud.com> (raw)
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.
Thanks,
Zizhi Wo
next reply other threads:[~2025-05-28 8:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 8:07 Zizhi Wo [this message]
2025-05-28 8:35 ` [QUESTION] cachefiles: Recovery concerns with on-demand loading after unexpected power loss Gao Xiang
2025-05-28 8:53 ` Zizhi Wo
2025-05-28 9:25 ` Gao Xiang
2025-05-28 9:58 ` Zizhi Wo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250528080759.105178-1-wozizhi@huaweicloud.com \
--to=wozizhi@huaweicloud.com \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=houtao1@huawei.com \
--cc=hsiangkao@linux.alibaba.com \
--cc=jefflexu@linux.alibaba.com \
--cc=jlayton@kernel.org \
--cc=libaokun1@huawei.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netfs@lists.linux.dev \
--cc=wozizhi@huawei.com \
--cc=yangerkun@huawei.com \
--cc=yukuai3@huawei.com \
--cc=zhujia.zj@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).