On Tue, Jan 7, 2020 at 11:03 AM Darrick J. Wong <darrick.wong(a)oracle.com> wrote:
> That can already happen today. If you do not properly align the
> partition then dax operations will be disabled.
Er... is this conversation getting confused? I was talking about
kpartx's /dev/mapper/pmem0p1 being a straight replacement for the kernel
creating /dev/pmem0p1. I thnk Vivek was complaining about the
inconsistent behavior between the two, even if the partition is aligned
I'm not sure how alignment leaked in here?
Oh, whoops, I was jumping to the mismatch between host device and
partition and whether we had precedent to fail to support dax on the
partition when the base block device does support it.
But yes, the mismatch between kpartx and native partitions is weird.
That said kpartx is there to add partition support where the kernel
for whatever reason fails to, or chooses not to, and dax is looking
like such a place.
> This proposal just
> extends that existing failure domain to make all partitions fail to
> support dax.
Oh, wait. You're proposing that "partitions of pmem devices don't
support DAX", not "the kernel will not create partitions for pmem
Yeah, that would be inconsistent and weird.
More weird than the current constraints?
I'd say deprecate the
kernel automounting partitions, but I guess it already does that, and
Ok, now I don't know why automounting is leaking into this discussion?
removing it would break /something/.
Yes, the breakage risk is anyone that was using ext4 mount failure as
a dax capability detector.
I guess you could put
"/dev/pmemXpY" on the deprecation schedule.
...but why deprecate /dev/pmemXpY partitions altogether? If someone
doesn't care about dax then they can do all the legacy block things.
If they do care about dax then work with whole device namespaces.
The proposal is to detect dax on partitions and warn people to move to
kpartx. Let the core fs/dax implementation continue to shed block