Re: [PATCH 14/15] libnvdimm: support read-only btt backing devices
From: Dan Williams
Date: Mon Jun 22 2015 - 12:37:06 EST
On Mon, Jun 22, 2015 at 8:40 AM, Christoph Hellwig <hch@xxxxxx> wrote:
> On Mon, Jun 22, 2015 at 12:39:34AM -0700, Dan Williams wrote:
>> Now I'm confused, you *don't* want the raw device to be hidden *and*
>> you want to kill the stacking? Something got crossed. The current
>> implementation hides nothing, you get to see the entire stacked
>> composition. I'd much prefer to avoid hiding anything.
>
> You see it, but you can't actually use it. The proper way to expose it
> would be to the devices visible in the low-level bus sysfs enumeration
> logic but only one ULD attach to it.
>
In that case "don't stack" is too coarse of a hammer. I see this as a
request to hide the subordinate ULD which is a new capability that DM
and MD might benefit from as well. We already have the case in MD
where it internally holds a reference to bdev that has been hot
removed, it seems not much of a stretch to have stacking drivers be
able to hide device nodes for bdevs that they are holding.
>> The sinister aspect of sector tearing is that most applications don't
>> know they have this dependency. At least today's disk's rarely ever
>> tear sectors and if they do you almost certainly get a CRC error on
>> access. NVDIMMs will always tear and always silently. I think not
>> merging BTT at all to see what happens is simply wrong.
>
> So now you leave your users with a choice between a rock and a hard
> place, that is using BTT to introduce non-significant overhead and not
> supporting DAX or just use it as-is.
Yes, if they want to use DAX they should do it consciously and audit
their application to be sure it is safe to abandon atomic sector
guarantees. With the current flexibility to do BTT on a partition
they can do this conversion piecemeal and, for example, keep metadata
on BTT and data on DAX.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/