Message-ID: <tencent_656F159830BC538C2D26CD68@qq.com>
Date: Fri, 1 Aug 2025 10:27:21 +0800
From: "Zhou Jifeng" <zhoujifeng@...inos.com.cn>
To: "Kent Overstreet" <kent.overstreet@...ux.dev>
Cc: "Coly Li" <colyli@...nel.org>, "linux-bcache" <linux-bcache@...r.kernel.org>, "linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bcache: enhancing the security of dirty data writeback

On Fri, 1 Aug 2025 at 00:02, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
>
> On Thu, Jul 31, 2025 at 02:21:40PM +0800, Zhou Jifeng wrote:
> > There is a potential data consistency risk in bcache's writeback mode:when
> > the application calls fsync, bcache returns success after completing the
> > log write, persisting the cache disk data, and persisting the HDD internal
> > cache. However, at this point, the actual application data may still be in
> > a dirty state and remain stuck in the cache disk. when these data are
> > subsequently written back to the HDD asynchronously through REQ_OP_WRITE,
> > there is no forced refresh mechanism to ensure physical placement on the
> > disk, and there may be no power-off protection measures, which poses a risk
> > of data loss. This mechanism may cause the application to misjudge that the
> > data has been persisted, which is different from the actual storage state,
> > and also violates the semantic agreement that fsync should ensure data
> > persistence.
>
> So, the way you start out describing the patch, it sounds like you're
> addressing some sort of bug in REQ_OP_FLUSH handling, but it looks like
> what you're actually doing is adding a mode where flushes also flush
> bcache?
>
> This doesn't sound like a bugfix, this sounds like a completely new
> mode - we'd need an explanation of the use case you're aiming for.

Yes, this is not about trying to fix a particular defect. Instead, it is about
adding a new method within the current writeback mode to make the
process of writing dirty data in the cache to the HDD more reliable.

> The model for bcache has always been that since the cache is persistent,
> when you're in writeback mode there are no fsync/REQ_OP_FLUSH
> considerations for dirty data; once we've properly persisted (and
> flushed) that data we're good.

In the writeback mode, the current bcache code uses the
REQ_OP_WRITE operation to handle dirty data, and clears the bkey
dirty flag in the btree during the bio completion callback. I think
there might be a potential risk: if in the event of an unexpected
power outage, the data in the HDD hardware cache may not have
had time to be persisted, then the data in the HDD hardware cache
that is pending processing may be lost. Since at this time the bkey
dirty flag in the btree has been cleared, the data status recorded
by the bkey does not match the actual situation of the SSD and
HDD.
Am I understanding this correctly?

> If you want a mode where you can run in writeback mode, but obey flushes
> so that it's still safe to lose or yank the cache device - is that what
> you're after?

When dirty data is temporarily stored in the HDD hardware cache (not
persistedto the disk medium), if an unexpected power outage or unplugging
occurs, the data in the HDD hardware cache may be lost. If such a scenario
occurs, since thedirty flag of the bkey in the btree has been cleared at this
time, but the actual dirtydata corresponding to the bkey has not been
successfully written back to the HDD. I want to use a method to avoid this
situation.

Powered by blists - more mailing lists