linux-kernel - Re: [RFC PATCH 00/11] pcache: Persistent Memory Cache for Block Devices

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <07f93a57-6459-46e2-8ee3-e0328dd67967@linux.dev>
Date: Wed, 16 Apr 2025 14:08:25 +0800
From: Dongsheng Yang <dongsheng.yang@...ux.dev>
To: Jens Axboe <axboe@...nel.dk>, Dan Williams <dan.j.williams@...el.com>,
 hch@....de, gregory.price@...verge.com, John@...ves.net,
 Jonathan.Cameron@...wei.com, bbhushan2@...vell.com, chaitanyak@...dia.com,
 rdunlap@...radead.org
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-cxl@...r.kernel.org, linux-bcache@...r.kernel.org,
 nvdimm@...ts.linux.dev
Subject: Re: [RFC PATCH 00/11] pcache: Persistent Memory Cache for Block
 Devices

On 2025/4/16 9:04, Jens Axboe wrote:
> On 4/15/25 12:00 PM, Dan Williams wrote:
>> Thanks for making the comparison chart. The immediate question this
>> raises is why not add "multi-tree per backend", "log structured
>> writeback", "readcache", and "CRC" support to dm-writecache?
>> device-mapper is everywhere, has a long track record, and enhancing it
>> immediately engages a community of folks in this space.
> Strongly agree.

Hi Dan and Jens,
Thanks for your reply, that's a good question.

     1. Why not optimize within dm-writecache?
     From my perspective, the design goal of dm-writecache is to be a 
minimal write cache. It achieves caching by dividing the cache device 
into n blocks, each managed by a wc_entry, using a very simple 
management mechanism. On top of this design, it's quite difficult to 
implement features like multi-tree structures, CRC, or log-structured 
writeback. Moreover, adding such optimizations—especially a read 
cache—would deviate from the original semantics of dm-writecache. So, we 
didn't consider optimizing dm-writecache to meet our goals.

     2. Why not optimize within bcache or dm-cache?
     As mentioned above, dm-writecache is essentially a minimal write 
cache. So, why not build on bcache or dm-cache, which are more complete 
caching systems? The truth is, it's also quite difficult. These systems 
were designed with traditional SSDs/NVMe in mind, and many of their 
design assumptions no longer hold true in the context of PMEM. Every 
design targets a specific scenario, which is why, even with dm-cache 
available, dm-writecache emerged to support DAX-capable PMEM devices.

     3. Then why not implement a full PMEM cache within the dm framework?
     In high-performance IO scenarios—especially with PMEM 
hardware—adding an extra DM layer in the IO stack is often unnecessary. 
For example, DM performs a bio clone before calling __map_bio(clone) to 
invoke the target operation, which introduces overhead.

Thank you again for the suggestion. I absolutely agree that leveraging 
existing frameworks would be helpful in terms of code review, and 
merging. I, more than anyone, hope more people can help review the code 
or join in this work. However, I believe that in the long run, building 
a standalone pcache module is a better choice.

Thanx
Dongsheng

>