RFC Block Layer Extensions to Support NV-DIMMs
jmoyer at redhat.com
Thu Sep 5 13:19:02 EDT 2013
Rob Gittins <rob.gittins at linux.intel.com> writes:
>> > void (*commitpmem)(struct block_device *bdev, void *addr);
>> Seems like this would benefit from a length argument as well, no?
> Yes. Great point. I will add that in.
Rob, taking it a step further, maybe a vectored interface would be more
flexible. Something to consider, anyway.
>> > Another area requiring extension is the need to be able to clear PMEM
>> > errors. When data is fetched from errored PMEM it is marked with the
>> > poison attribute. If the CPU attempts to access the data it causes a
>> > machine check. How errors are cleared is hardware dependent and needs
>> > to be handled by the specific device driver. The following function
>> > in the block_device_operations vector would clear the correct range
>> > of PMEM and put new data there. If the argument data is null or the
>> > size is zero the driver is free to put any data in PMEM it wishes.
>> > void (*clearerrorpmem)(struct block_device *bdev, void *addr,
>> > size_t len, void *data);
>> What is the size of data?
> clearerrorpmem as part of the process of clearing an error
> can effectively write a buffer of data as part of the
> clear process. If the len is zero or the data pointer is null then
> only a error clear happens.
So data would be of 'len' size, then? In other words, this would be a
way to restore data that may have been there?
> The existing partitioning mechanism was intended for small drives
> and works best for a single fs/device. We are approaching NV-DIMMs
> as if they were more like LUNs in storage arrays. Each range is
> treated as a device. A range of an NV-DIMM could be partitioned if
> someone wanted to do such a thing.
OK, that clears things up, thanks.
More information about the Linux-pmfs