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@xxxxxxxxxxxx > https://lists.01.org/mailman/listinfo/linux-nvdimm -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
