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 conn
On Thu, Jul 6, 2017 at 12:11 PM, h...@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 wrote:
>> > On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote:
>> [..]
>> >> We have syml
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 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
> >> sto
[ adding Jeff, and Johannes ]
On Wed, Jul 5, 2017 at 6:17 PM, Kani, Toshimitsu 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 vo
On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote:
> On Wed, Jul 5, 2017 at 4:46 PM, Kani, Toshimitsu
> wrote:
> > On Thu, 2017-06-29 at 18:28 -0700, Dan Williams wrote:
:
> >
> > Sorry for being late to respond, but I agree with Linda that this
> > naming policy is likely to confuse users.
On Wed, Jul 5, 2017 at 4:46 PM, Kani, Toshimitsu wrote:
> On Thu, 2017-06-29 at 18:28 -0700, Dan Williams wrote:
>> On Thu, Jun 29, 2017 at 4:14 PM, Linda Knippers > om> wrote:
>> > On 06/29/2017 06:58 PM, Dan Williams wrote:
>> > > On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers > > > pe.com> wro
On Thu, 2017-06-29 at 18:28 -0700, Dan Williams wrote:
> On Thu, Jun 29, 2017 at 4:14 PM, Linda Knippers om> wrote:
> > On 06/29/2017 06:58 PM, Dan Williams wrote:
> > > On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers > > pe.com> wrote:
> > > > > The parent region of the namespace will have a 'vo
On Thu, Jun 29, 2017 at 4:14 PM, Linda Knippers wrote:
> On 06/29/2017 06:58 PM, Dan Williams wrote:
>> On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers
>> wrote:
The parent region of the namespace will have a 'volatile' type:
# cat /sys/bus/nd/devices/region0/devtype
nd_volat
On 06/29/2017 06:58 PM, Dan Williams wrote:
> On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers
> 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
On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers 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/d
On 6/29/2017 6:43 PM, Dan Williams wrote:
On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers wrote:
On 06/29/2017 06:28 PM, Dan Williams wrote:
On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers wrote:
[..]
The /dev/pmem
device name just tells you that your block device is hosted by a
driver tha
On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers wrote:
> On 06/29/2017 06:28 PM, Dan Williams wrote:
>> On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers
>> wrote:
>> [..]
The /dev/pmem
device name just tells you that your block device is hosted by a
driver that knows how to handle
On 06/29/2017 06:28 PM, Dan Williams wrote:
> On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers
> wrote:
> [..]
>>> The /dev/pmem
>>> device name just tells you that your block device is hosted by a
>>> driver that knows how to handle persistent memory constraints, but any
>>> other details about t
On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers wrote:
[..]
>> The /dev/pmem
>> device name just tells you that your block device is hosted by a
>> driver that knows how to handle persistent memory constraints, but any
>> other details about the nature of the address range need to come from
>> oth
On 6/29/2017 5:50 PM, Dan Williams wrote:
On Thu, Jun 29, 2017 at 2:16 PM, Linda Knippers wrote:
On 06/29/2017 04:42 PM, Dan Williams wrote:
On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers wrote:
On 06/29/2017 01:54 PM, Dan Williams wrote:
Allow volatile nfit ranges to participate in all
On Thu, Jun 29, 2017 at 2:16 PM, Linda Knippers wrote:
> On 06/29/2017 04:42 PM, Dan Williams wrote:
>> On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers
>> wrote:
>>> On 06/29/2017 01:54 PM, Dan Williams wrote:
Allow volatile nfit ranges to participate in all the same infrastructure
pr
On 06/29/2017 04:42 PM, Dan Williams wrote:
> On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers
> wrote:
>> On 06/29/2017 01:54 PM, Dan Williams wrote:
>>> Allow volatile nfit ranges to participate in all the same infrastructure
>>> provided for persistent memory regions.
>>
>> This seems to be a
On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers wrote:
> On 06/29/2017 01:54 PM, Dan Williams wrote:
>> Allow volatile nfit ranges to participate in all the same infrastructure
>> provided for persistent memory regions.
>
> This seems to be a bit more than "other rework".
It's part of the ration
On 06/29/2017 01:54 PM, Dan Williams wrote:
> Allow volatile nfit ranges to participate in all the same infrastructure
> provided for persistent memory regions.
This seems to be a bit more than "other rework".
> A resulting resulting namespace
> device will still be called "pmem", but the parent
Allow volatile nfit ranges to participate in all the same infrastructure
provided for persistent memory regions. A resulting resulting namespace
device will still be called "pmem", but the parent region type will be
"nd_volatile". This is in preparation for disabling the dax ->flush()
operation in
20 matches
Mail list logo