On Thu, Jan 16, 2020 at 10:09:46AM -0800, Dan Williams wrote:
On Wed, Jan 15, 2020 at 1:08 PM Jeff Moyer <jmoyer(a)redhat.com>
> Hi, Dan,
> Dan Williams <dan.j.williams(a)intel.com> writes:
> > I'm going to take a look at how hard it would be to develop a kpartx
> > fallback in udev. If that can live across the driver transition then
> > maybe this can be a non-event for end users that already have that
> > udev update deployed.
> I just wanted to remind you that label-less dimms still exist, and are
> still being shipped. For those devices, the only way to subdivide the
> storage is via partitioning.
True, but if kpartx + udev can make this transparent then I don't
think users lose any functionality. They just gain a device-mapper
Are you planning to look into making this work?
We can easily disable partition scanning by specifying gendisk
GENHD_FL_NO_PART_SCAN flag. But what about partition additiona path,
ioctl(BLKPG_ADD_PARTITION). That does not seem to do any checks whether
block device supports in kernel partitions or not.
So kernel partitions (hence /dev/pmemXpY) objects are created anyway and
this will conflict with all the new planned udev rules.
If you block ioctl(BLKPG_ADD_PARTITION), then user space tools like
parted and fdisk started breaking when trying to create a partition
on /dev/pmeme0. IIUC, we have to allow partition table creation on
/dev/pmem0 so that later kpartx can parse it and create dm-linear