From: Keith Busch <kbusch@kernel.org>
To: Stefan <linux-kernel@simg.de>
Cc: Christoph Hellwig <hch@lst.de>,
Thorsten Leemhuis <regressions@leemhuis.info>,
bugzilla-daemon@kernel.org, Bruno Gravato <bgravato@gmail.com>,
Adrian Huang <ahuang12@lenovo.com>,
Linux kernel regressions list <regressions@lists.linux.dev>,
linux-nvme@lists.infradead.org, Jens Axboe <axboe@fb.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Bug 219609] File corruptions on SSD in 1st M.2 socket of AsRock X600M-STX + Ryzen 8700G
Date: Fri, 17 Jan 2025 18:03:49 -0700 [thread overview]
Message-ID: <Z4r99SQYV9v5vBuR@kbusch-mbp> (raw)
In-Reply-To: <00b01ab3-ec9d-4a35-a593-c9fc764e0f04@simg.de>
On Fri, Jan 17, 2025 at 10:31:55PM +0100, Stefan wrote:
> As already mentioned, my SSD has no DRAM and uses HMB (Host memory
> buffer).
HMB and volatile write caches are not necessarily intertwined. A device
can have both. Generally speaking, you'd expect the HMB to have SSD
metadata, not user data, where a VWC usually just has user data. The
spec also requires the device maintain data integrity even with an
unexpected sudden loss of access to the HMB, but that isn't the case
with a VWC.
>(It has non-volatile SLC cache.) Disabling volatile write cache
> has no significant effect on read/write performance of large files,
Devices are free to have whatever hierarchy of non-volatile caches they
want without advertising that to the host, but if they're calling those
"volatile" then I think something has been misinterpreted.
> because the HMB size in only 40MB. But things like file deletions may be
> slower.
>
> AFAIS the corruption occur with both kinds of SSD's, the ones that have
> own DRAM and he ones that use HMB.
Yeah, that was the point of the experiment. If corruption happens when
it's off, then that helps rule out host buffer size/alignment (which is
where this bz started) as a triggering condition. Disabling VWC is not a
"fix", it's just a debug data point. If corruption goes away with it
off, though, then we can't really conclude anything for this issue.
next prev parent reply other threads:[~2025-01-18 1:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 14:38 [Regression] File corruptions on SSD in 1st M.2 socket of AsRock X600M-STX Thorsten Leemhuis
2025-01-08 15:07 ` Keith Busch
2025-01-09 8:28 ` Christoph Hellwig
2025-01-09 8:52 ` Thorsten Leemhuis
2025-01-09 15:44 ` [Bug 219609] File corruptions on SSD in 1st M.2 socket of AsRock X600M-STX + Ryzen 8700G Stefan
2025-01-10 11:17 ` Bruno Gravato
2025-01-15 6:37 ` Bruno Gravato
2025-01-15 8:40 ` Thorsten Leemhuis
2025-01-16 17:29 ` Thorsten Leemhuis
2025-01-17 8:05 ` Christoph Hellwig
2025-01-17 9:51 ` Thorsten Leemhuis
2025-01-17 9:55 ` Christoph Hellwig
2025-01-17 10:30 ` Thorsten Leemhuis
2025-02-04 6:26 ` Christoph Hellwig
2025-01-17 13:36 ` Bruno Gravato
2025-01-20 14:31 ` Thorsten Leemhuis
2025-01-28 7:41 ` Christoph Hellwig
2025-01-28 12:00 ` Stefan
2025-01-28 12:52 ` Dr. David Alan Gilbert
2025-01-28 14:24 ` Stefan
2025-02-02 8:32 ` Bruno Gravato
2025-02-04 6:12 ` Christoph Hellwig
2025-02-04 9:12 ` Bruno Gravato
2025-02-03 18:48 ` Stefan
2025-02-06 15:58 ` Stefan
2025-01-17 21:31 ` Stefan
2025-01-18 1:03 ` Keith Busch [this message]
2025-01-15 10:47 ` Stefan
2025-01-15 13:14 ` Bruno Gravato
2025-01-15 16:26 ` Stefan
2025-01-10 0:10 ` [Regression] File corruptions on SSD in 1st M.2 socket of AsRock X600M-STX Keith Busch
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=Z4r99SQYV9v5vBuR@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=ahuang12@lenovo.com \
--cc=axboe@fb.com \
--cc=bgravato@gmail.com \
--cc=bugzilla-daemon@kernel.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=linux-kernel@simg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
/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