Re: RFC Block Layer Extensions to Support NV-DIMMs

[Jeff Moyer <jmoyer@redhat.com>]

Rob Gittins <rob.gittins@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.

-Jeff