On Tue, Jan 7, 2020 at 11:03 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> 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 > properly. > > 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 > devices". > > 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 dependencies.
