Re: [Linux-nvdimm] [PATCH v2 08/20] libnd, nd_acpi: regions (block-data-window, persistent memory, volatile memory)

From: Dan Williams
Date: Thu May 28 2015 - 16:58:49 EST


On Thu, May 28, 2015 at 1:51 PM, Linda Knippers <linda.knippers@xxxxxx> wrote:
> On 5/28/2015 3:59 PM, Dan Williams wrote:
>> On Thu, May 28, 2015 at 11:36 AM, Toshi Kani <toshi.kani@xxxxxx> wrote:
>>> On Sat, 2015-05-09 at 16:55 -0700, Dan Williams wrote:
>>>> On Mon, May 4, 2015 at 1:26 PM, Toshi Kani <toshi.kani@xxxxxx> wrote:
>>>>> On Tue, 2015-04-28 at 14:24 -0400, Dan Williams wrote:
>>> :
>>>>>
>>>>> The libnd does not support memdev->flags, which contains "Memory Device
>>>>> State Flags" defined in Table 5-129 of ACPI 6.0. In case of major
>>>>> errors, we should only allow a failed NVDIMM be accessed with read-only
>>>>> for possible data recovery (or not allow any access when the data is
>>>>> completely lost), and should not let users operate normally over the
>>>>> corrupted data until the error is dealt properly.
>>>>
>>>> I agree with setting read-only access when these flags show that the
>>>> battery is not ready to persist new writes, but I don't think we
>>>> should block access in the case where the restore from flash failed.
>>>> If the data is potentially corrupted we should log that fact, but
>>>> otherwise enable access. I.e. potentially corrupt data is better than
>>>> unavailable data. It's up to filesystem or application to maintain
>>>> its own checksums to catch data corruption.
>>>>
>>>>> Can you set memdev->flags to nd_region(_desc) so that the pmem driver
>>>>> can check the status in nd_pmem_probe()? nd_pmem_probe() can then set
>>>>> the disk read-only or fail probing, and log errors accordingly.
>>>>
>>>> Will do.
>>>
>>> I do not see this change in v4. Is this part of the pending changes
>>> behind this release?
>>
>> Yes, I was holding it off until we had an upstream acceptance baseline
>> set. That is on hold pending Christoph's review. He's looking to
>> come back next Wednesday with deeper review comments. The runway to
>> land this in v4.2 is running short...
>
> Hi Dan,
>
> Do you have a short list of pending changes, especially if some weren't
> discussed on the list? That might help reviewers.
>
> I know we're still looking at and trying a number of things, like using
> the BTT on today's NVDIMMs and adding another example DSM, so we will
> have more feedback and patches and may need to adapt some of the
> structure to do that. This can happen after the initial patches are
> pulled in but I just wanted to let you know where we are. Not sure
> about others.
>

It seems it's just Christoph that has asserted there are things he'd
liked changed, so I don't see much potential for confusion in letting
out the pending backlog. I'll see to it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/