NVMf initiator persistent across boots

[Max Gurtovoy]

On 3/8/2018 3:26 PM, Johannes Thumshirn wrote:
> On Thu, Mar 08, 2018 at 03:15:42PM +0200, Max Gurtovoy wrote:
>> Yes, I got it.
>> IMO if you will add:
>> -t rdma -a 1.1.1.1 -s 4420 -w 1.1.1.2
>> -t rdma -a 1.1.1.1 -s 4420 -w 1.1.1.3
>>
>> to the discovery file it should be fine.
>> I think we'll need to fix few things in nvmecli and in the driver too.
>> I'm checking this.
> 
> Hmm interesting. This probably was too obvious for me to try...
> 

worked for me with:

diff --git a/fabrics.c b/fabrics.c
index 4bdaaf2..774d5dc 100644
--- a/fabrics.c
+++ b/fabrics.c
@@ -614,6 +614,14 @@ static int connect_ctrl(struct 
nvmf_disc_rsp_page_entry *e)
                 p += len;
         }

+       if (cfg.host_traddr) {
+               len = sprintf(p, ",host_traddr=%s", cfg.host_traddr);
+               if (len < 0)
+                       return -EINVAL;
+               p+= len;
+       }
+
+
         switch (e->trtype) {
         case NVMF_TRTYPE_LOOP: /* loop */
                 len = sprintf(p, ",transport=loop");
@@ -659,11 +667,6 @@ static int connect_ctrl(struct 
nvmf_disc_rsp_page_entry *e)
                                 return -EINVAL;
                         p += len;

-                       len = sprintf(p, ",host_traddr=%s", 
cfg.host_traddr);
-                       if (len < 0)
-                               return -EINVAL;
-                       p+= len;
-
                         len = sprintf(p, ",traddr=%.*s",
                                       space_strip_len(NVMF_TRADDR_SIZE, 
e->traddr),
                                       e->traddr);


thoughts ?


>>> Good question. I'd be fine with both. The only thing that should be
>>> considered as well is, if you already need the nvmf connection in the
>>> initrd, you'll have to rebuild the initrd after each change of
>>> /etc/nvme/discovery.conf and thus every nvme
>>> persist-add/persist-remove (or discover --persistent) call.
>>
>> Let's assume that we don't need it for now, otherwise it will be unpleasent
>> :)
> 
> Given the number of "Boot from SAN failed with XXX" Bugs I have seen
> the last years I doubt we won't need it ;-).
> 
> But yes we can think about this in step two I guess.
>