Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1681962 > unrolled thread

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges Dan Williams <dan.j.williams@intel.com> - 2017-07-06 02:10 +0200
    Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges Dan Williams <dan.j.williams@intel.com> - 2017-07-06 04:10 +0200
      Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile         ranges "hch@lst.de" <hch@lst.de> - 2017-07-06 04:20 +0200
        Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges Oliver <oohall@gmail.com> - 2017-07-06 05:00 +0200
          Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile         ranges "hch@lst.de" <hch@lst.de> - 2017-07-06 05:00 +0200

#1681962 — Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Wed, Jul 5, 2017 at 4:46 PM, Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> On Thu, 2017-06-29 at 18:28 -0700, Dan Williams wrote:
>> On Thu, Jun 29, 2017 at 4:14 PM, Linda Knippers <linda.knippers@hpe.c
>> om> wrote:
>> > On 06/29/2017 06:58 PM, Dan Williams wrote:
>> > > On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers <linda.knippers@h
>> > > pe.com> wrote:
>> > > > > The parent region of the namespace will have a 'volatile'
>> > > > > type:
>> > > > >
>> > > > > # cat /sys/bus/nd/devices/region0/devtype
>> > > > > nd_volatile
>> > > >
>> > > >
>> > > > If all I know is the /dev/pmem device name, how do I find that?
>> > > >
>> > >
>> > >     cat $(readlink -f /sys/block/pmem0/device)/../devtype
>> > >
>> > > ...this is where 'ndctl list' will get the information.
>> > >
>> >
>> > Thanks.
>> >
>> > I think we need a section 4 pmem manpage like exists for
>> > mem, sd, fd, md, etc., where we can put stuff like this, as well
>> > as providing some overview information that will point people to
>> > other resources.  I'll give that some thought unless there is one
>> > already that I'm not finding.
>> >
>>
>> A "pmem" man page sounds like a great idea, I wasn't aware we even
>> had an sd man page.
>
> Sorry for being late to respond, but I agree with Linda that this
> naming policy is likely to confuse users.  I also care less about the
> current users who use memmap option.  This case is pmem-emulation and
> they know what they are doing.
>
> Assuming block device interface is needed (in addition to device-dax)
> for volatile range for use-cases like swap device, I wonder if user can
> actually specify a right pmem device for swap from OS-install GUI when
> both volatile and persistent block devices are listed as /dev/pmemN.
> Sometimes we are restricted with GUI menu.  Some users use GUI all the
> time like Windows as well.
>
> Can we differentiate the naming by adding 'v' like 'pmemNv' (if you
> can't go with 'vmemN')?  I don't think having 's' for BTT was that bad.
>  It's been helpful to tell users that these pmem devices are not byte-
> addressable.  I also think that BTT for volatile range makes no sense
> (unless emulated as persistent memory by memmap option).

I'm more worried about sending the wrong signal the other way. That
users believe that the 'p' means definitely "persistent" when we have
no way to guarantee that.

If it was only memmap= that we had to worry about that would be one
thing, but we apparently have vendors that are shipping "e820-type-12
memory" as their NVDIMM solution [1].

We've also been shipping the policy that 'pmem' may front a volatile
range ever since v4.8 (commit c2f32acdf848 "acpi, nfit: treat virtual
ramdisk SPA as pmem region"). At least now we have the "nd_volatile"
region type. Any change of the device name now is potentially a
regression for environments that are already expecting /dev/pmemX.

As far as I know there are no OS installers that understand pmem. When
they do add support I think it would be straightforward to avoid
confusion and filter "volatile" hosted pmem devices from the install
target list. I don't see this being much different from the confusion
when users can not differentiate their 'sd' device between USB and
SATA. We have symlinks in /dev/disk/by* to make it easier to identify
storage devices, I think it makes sense to add udev rules for
identifying volatile pmem and not try to differentiate this in the
default kernel device name.

[1]: https://github.com/pmem/ndctl/issues/21

[toc] | [next] | [standalone]

#1682011

[ adding Jeff, and Johannes ]

On Wed, Jul 5, 2017 at 6:17 PM, Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote:
[..]
>> We have symlinks in /dev/disk/by* to make it easier to identify
>> storage devices, I think it makes sense to add udev rules for
>> identifying volatile pmem and not try to differentiate this in the
>> default kernel device name.
>
> I am not sure what might be a good way, but I am concerned because a
> single block device naming do not represent both volatile and
> persistent media today.

We do have time to changes this if we find out this is critical. Maybe
it's best to ask Linux distro folks what would be easier for them?

Jeff, Johannes, any thoughts on whether we should produce a
"/dev/vmemX" device when we know the backing memory range is volatile?
In this patch everything shows up as /dev/pmemX and you need to look
elsewhere in sysfs to find that the memory range is defined as
volatile by the NFIT.

[toc] | [prev] | [next] | [standalone]

#1682014 — Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Wed, Jul 05, 2017 at 07:08:54PM -0700, Dan Williams wrote:
> [ adding Jeff, and Johannes ]
> 
> On Wed, Jul 5, 2017 at 6:17 PM, Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> > On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote:
> [..]
> >> We have symlinks in /dev/disk/by* to make it easier to identify
> >> storage devices, I think it makes sense to add udev rules for
> >> identifying volatile pmem and not try to differentiate this in the
> >> default kernel device name.
> >
> > I am not sure what might be a good way, but I am concerned because a
> > single block device naming do not represent both volatile and
> > persistent media today.
> 
> We do have time to changes this if we find out this is critical. Maybe
> it's best to ask Linux distro folks what would be easier for them?

I'm not really concerned about it, because SCSI devices for example
might not be persistent as well with ѕcsi_debug, target_core_rd or
volatile qemu devices.

That being said I really don't understand the purpose of these volatile
nfit ranges.  Are they seen in the wild?  If yes what's the use case?
If not why do we even need to support them?

[toc] | [prev] | [next] | [standalone]

#1682023

On Thu, Jul 6, 2017 at 12:11 PM, hch@lst.de <hch@lst.de> wrote:
> On Wed, Jul 05, 2017 at 07:08:54PM -0700, Dan Williams wrote:
>> [ adding Jeff, and Johannes ]
>>
>> On Wed, Jul 5, 2017 at 6:17 PM, Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
>> > On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote:
>> [..]
>> >> We have symlinks in /dev/disk/by* to make it easier to identify
>> >> storage devices, I think it makes sense to add udev rules for
>> >> identifying volatile pmem and not try to differentiate this in the
>> >> default kernel device name.
>> >
>> > I am not sure what might be a good way, but I am concerned because a
>> > single block device naming do not represent both volatile and
>> > persistent media today.
>>
>> We do have time to changes this if we find out this is critical. Maybe
>> it's best to ask Linux distro folks what would be easier for them?
>
> I'm not really concerned about it, because SCSI devices for example
> might not be persistent as well with ѕcsi_debug, target_core_rd or
> volatile qemu devices.
>
> That being said I really don't understand the purpose of these volatile
> nfit ranges.  Are they seen in the wild?  If yes what's the use case?
> If not why do we even need to support them?

The main use case is provisioning install media for bare metal
servers. Traditionally that's been handled by having the BMC emulate a
USB CD drive. Unfortunately, most BMCs have limited CPU, limited
memory and a wet-string network connection so a host based alternative
is nice to have.

[toc] | [prev] | [next] | [standalone]

#1682024 — Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jul 06, 2017 at 12:53:13PM +1000, Oliver wrote:
> The main use case is provisioning install media for bare metal
> servers. Traditionally that's been handled by having the BMC emulate a
> USB CD drive. Unfortunately, most BMCs have limited CPU, limited
> memory and a wet-string network connection so a host based alternative
> is nice to have.

If they are CD replacement they should be marked as read-only, which
would solve any concerns about them being volatile or not.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web