All of lore.kernel.org
 help / color / mirror / Atom feed
From: maxg@mellanox.com (Max Gurtovoy)
Subject: NVMf initiator persistent across boots
Date: Sun, 4 Mar 2018 17:56:31 +0200	[thread overview]
Message-ID: <21e13bdf-d7a4-b47b-0885-855ba5ed995b@mellanox.com> (raw)
In-Reply-To: <20170830094553.GC3941@linux-x5ow.site>

Hi all,

Sorry for the delay, but I wanted to know if we had a progress for this 
topic. I want to add functionality that gives persistency for fabric 
devices not only across boots but also across adapter/device removals.
My idea is to add a flag --persist to "nvme connect" command. This 
command will add the created ctrls to a file 
(/etc/nvme-fabrics/persistent_ctrls for example).
And I want to add a udev rule that in case of ctrl removal, we'll run a 
script that try to periodicly connect to the target.

thoughts ?

On 8/30/2017 12:45 PM, Johannes Thumshirn wrote:
> [+Cc James]
> 
> On Wed, Aug 30, 2017@12:37:47PM +0300, Sagi Grimberg wrote:
> [...]
>> Something like:
>> --
>> [Unit]
>> Description=NVMf auto discovery service
>> After=systemd-modules-load.service network-online.target
>>
>> [Service]
>> Type=oneshot
>> ExecStart=/usr/bin/nvme connect-all
>> StandardOutput=journal
>>
>> [Install]
>> WantedBy=multi-user.target
>> --
>>
>> Where discovery.conf would have the relevant parameters
>> like:
>> --
>> --traddr=<traddr1> --trsvcid=<trsvcid1>
>> --traddr=<traddr2> --trsvcid=<trsvcid2>
>> --
>>
>> One thing we may want to have is to make sure
>> that nvme relevant modules are loaded at boot time
>> so we may want nvme-cli to either manually load them
>> or the installation would add them to systemd-modules-load.service
>> (i.e. add relevant files to /etc/modules-load.d/)
>>
>> Thoughts?
> 
> That's exactly what I wanted to do for SUSE distros as well, so I'm fine with
> it.
> 
> James Smart has a bunch of scripts and udev rules for FC-NVMe autoconnecting
> and I asked him earlier today to sumbit them here as well.

Can you share these rules so we can create something generic ?

> 
> Byte,
> 	Johannes
> 

Cheers,
Max.

  reply	other threads:[~2018-03-04 15:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-28 15:00 NVMf initiator persistent across boots Narasimhan V
2017-08-30  9:37 ` Sagi Grimberg
2017-08-30  9:45   ` Johannes Thumshirn
2018-03-04 15:56     ` Max Gurtovoy [this message]
2018-03-05 19:45       ` Sagi Grimberg
2018-03-07 12:47         ` Max Gurtovoy
2018-03-08  8:39           ` Johannes Thumshirn
2018-03-08 10:03             ` Max Gurtovoy
2018-03-08 10:13               ` Johannes Thumshirn
2018-03-08 13:15                 ` Max Gurtovoy
2018-03-08 13:26                   ` Johannes Thumshirn
2018-03-08 17:04                     ` Max Gurtovoy
2018-03-09  7:52                       ` Johannes Thumshirn
2018-03-07 15:48         ` Hannes Reinecke
2018-03-07 16:36           ` Max Gurtovoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21e13bdf-d7a4-b47b-0885-855ba5ed995b@mellanox.com \
    --to=maxg@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.