[dm-devel] Persistent memory interface

Verma, Vishal L vishal.l.verma at intel.com
Fri Jun 19 16:50:20 UTC 2015


On Fri, 2015-06-19 at 12:33 -0400, Mikulas Patocka wrote:
> Hi
> 
> I looked at the new the persistent memory block device driver 
> (drivers/block/pmem.c and arch/x86/kernel/pmem.c) and it seems that the 
> interface between them is incorrect.
> 
> If I want to use persistent memory in another driver, for a different 
> purpose, how can I make sure that that drivers/block/pmem.c doesn't attach 
> to this piece of memory and export it? It seems not possible. 
> drivers/block/pmem.c attaches to everything without regard that there may 
> be other users of persistent memory.
> 
> I think a correct solution would be to add a partition table at the 
> beginning of persistent memory area and this partition table would 
> describe which parts belong to which programs - so that different programs 
> could use persistent memory and not step over each other's data. Is there 
> some effort to standardize the partition table ongoing?
> 
> 
> BTW. some journaling filesystems assume that 512-byte sector is written 
> atomically. drivers/block/pmem.c breaks this requirement. Persistent 
> memory only gurantees 8-byte atomic writes.

Hi Mikulas,

I can answer this part - The idea is that file systems that need sector
atomicity will use the "Block Translation Table" (BTT) [1]. It would be
a stacked block device on top of a pmem device (or partition), and file
systems would be able to use it either for the entire space to get
atomicity for all blocks, or if they want to use DAX, make two
partitions, and enable the BTT only on one partition, and use it as the
logdev.

	-Vishal

[1]: https://lkml.org/lkml/2015/6/17/950

> 
> Mikulas
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm at lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm





More information about the dm-devel mailing list