[00:42:55] *** Joins: tomzawadzki (~tomzawadz@192.55.54.40) [01:26:44] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [03:07:09] *** Joins: tzawadzki (~tomzawadz@192.55.54.40) [03:10:10] *** Quits: tomzawadzki (~tomzawadz@192.55.54.40) (Ping timeout: 260 seconds) [03:10:17] *** Quits: tzawadzki (~tomzawadz@192.55.54.40) (Remote host closed the connection) [03:10:30] *** Joins: tzawadzki (~tomzawadz@192.55.54.40) [03:18:42] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [04:05:05] *** Quits: tzawadzki (~tomzawadz@192.55.54.40) (Remote host closed the connection) [04:09:28] *** Joins: tomzawadzki (~tomzawadz@192.55.54.40) [04:12:46] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [05:49:00] *** Joins: sbasierx (sbasierx@nat/intel/x-cbtoocwqiebtmsyf) [05:49:05] hi [05:50:53] i have 2 patches in lvol rename subject, waiting for review for a few days, can i ask you, jimharris or bwalker to look at them? [05:50:54] https://review.gerrithub.io/#/c/391411/ [05:50:59] https://review.gerrithub.io/#/c/392659/ [05:51:47] i would be grateful [06:28:15] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [06:53:58] *** Quits: sbasierx (sbasierx@nat/intel/x-cbtoocwqiebtmsyf) (Remote host closed the connection) [07:42:59] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [08:05:05] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [08:23:28] *** Quits: tomzawadzki (~tomzawadz@192.55.54.40) (Remote host closed the connection) [08:23:35] *** Joins: tomzawadzki (~tomzawadz@192.55.54.40) [08:39:11] *** Quits: tomzawadzki (~tomzawadz@192.55.54.40) (Ping timeout: 248 seconds) [08:40:35] *** Quits: darsto (~dstojacx@192.55.54.41) (*.net *.split) [08:40:37] *** Quits: klateck (~klateck@192.55.54.41) (*.net *.split) [08:40:37] *** Quits: pawelkax (~pawelkax@192.55.54.41) (*.net *.split) [08:40:37] *** Quits: gangcao (~gangcao@192.55.54.41) (*.net *.split) [08:40:46] *** Joins: tomzawadzki (~tomzawadz@192.55.54.40) [08:41:51] *** Joins: pawelkax (pawelkax@nat/intel/x-xjapwnsthoryfcfg) [08:42:19] *** Joins: klateck (klateck@nat/intel/x-gijyxkqboqhyklqk) [08:43:47] *** Joins: darsto (dstojacx@nat/intel/x-krxcajwqsoaqbyyt) [08:44:10] *** darsto is now known as Guest61754 [08:44:20] *** Joins: gangcao (gangcao@nat/intel/x-kthdcxtcircgsqzz) [09:02:04] *** Joins: lhodev (~Adium@inet-hqmc07-o.oracle.com) [09:08:42] *** Quits: tomzawadzki (~tomzawadz@192.55.54.40) (Ping timeout: 256 seconds) [09:09:07] drv, QQ for you on https://review.gerrithub.io/#/c/390709/ when you get a chance (test port) [09:10:20] drv, oops sorry meant this one: https://review.gerrithub.io/#/c/390930/ [09:29:53] *** Joins: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) [09:29:59] *** ChanServ sets mode: +o bwalker_ [09:38:48] *** Guest61754 is now known as darsto [09:58:27] bdev aliases are not persistent in the general case, right? [09:58:49] like if I set an alias to an NVMe device, then restart my application, that alias will only exist if my configuration file is holding that info [09:59:16] if I just did it through an RPC and threw away the mapping from device to alias, it would be gone [09:59:51] lvol aliases would be persistent [10:00:18] uuid is the primary name, user specified "friendly" name would be the alias [10:00:18] that's where my question is coming from [10:00:41] but that's a different model than the other bdevs [10:01:22] maybe - I could see us using NVMe serial number as primary name for nvme bdevs, and PCI bdf as an alias [10:01:49] then there's the question of which aliases persist and which don't [10:02:03] there's no intuitive way to know that [10:02:19] besides know how it is all implemented in each case [10:02:29] it's similar to which symlinks are psersisted [10:02:32] in Linxu kernel [10:04:31] and today you have do specifically the "lvol_bdev_rename" rpc to get it to persist - if you just do the bdev set alias rpc, it won't [10:04:48] even if it actually is an lvol bdev [10:06:51] I almost think a more intuitive model is to make set/del alias a module callback [10:06:55] that is optional [10:07:06] and if a module doesn't provide it, the aliases don't persist [10:25:58] I think we don't have bdev_set_alias - we have bdev_set_temporary_alias [10:26:04] or something indicating that alias is not persistent [11:31:41] *** Quits: lhodev (~Adium@inet-hqmc07-o.oracle.com) (Quit: Leaving.) [12:41:21] *** Joins: lhodev (~Adium@inet-hqmc07-o.oracle.com) [13:46:03] jimharris: do you know why the iSCSI DefaultTime2Wait and DefaultTime2Retain parameters have this comment about "incorrect values might crash"? [13:46:16] that seems untrue, or if it is true, we should fix it rather than just having a vague comment... [13:48:44] we should just remove those parameters entirely - we don't support full ERL2 which is where these parameters would be needed [13:48:57] sounds good to me [13:49:12] meaning keep the internals of it - have defaults which are used during negotiation - but remove the ability for users to change those values [13:49:13] it looks like the comment was in the initial istgt import [14:31:42] what's the status of these vhost intermittent failures? [14:31:45] is someone looking into it? [14:32:29] * peluse hears crickets... [14:58:06] *** Joins: AlanP_ (94571712@gateway/web/freenode/ip.148.87.23.18) [15:09:40] I was just looking at those [15:09:44] yeah - they're everywhere [15:13:38] this looks ominous: vhost.c: 338:spdk_vhost_vring_desc_to_iov: *ERROR*: SPDK_VHOST_IOVS_MAX(128) reached [15:17:18] that message is only seen in failing runs [15:18:24] did we update VMs or anything in the test pool? [15:25:02] I don't think the guest VMs have been updated, but we did do a host OS updated on all the test machines last week, I believe [15:28:27] master builds 4061 through 4075 all passed [15:28:44] 4076 failed, as did 4 of the 5 builds after that (plus more after that) [15:29:08] 4076 is configure: try harder to find Python interpreter [15:29:50] I'm pretty sure it's been failing intermittently for months [15:29:56] unless this is something new/different [15:30:30] the one I was just looking at (master build 4085) failed during vm_shutdown_all [15:31:02] which SSHs into the guest and runs 'shutdown' [15:31:46] all the ones I'm seeing have that SPDK_VHOST_IOVS_MAX error message which then results in an fio failure [15:33:12] i'll bet it's fio 3.3 [15:33:24] I think sethhowe did update everything to use fio 3.3 [15:34:50] the test does up to 512KB I/O, and we define SPDK_VHOST_IOVS_MAX to 128 - if fio 3.3 changed something where a 512KB I/O was no longer 4KB aligned, you'd hit this issue [15:40:15] is there any way to report this limit via the vhost protocol? [15:40:35] will this start failing if the user sends 768 KB instead of 512 KB? [15:40:35] no [15:41:37] yes - vhost needs to do splitting similar to iscsi [15:51:56] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [15:51:58] it's not clear to me yet what in fio could be causing this though [15:53:21] Hi All, please share with us when the next version is planned to be released and what is the number of the next version. [15:53:34] Our product team would like to know that. Thank you. [15:55:42] hi Shuhei [15:55:51] next version is planned in next two weeks and will be v18.01 [15:56:15] Hi Jim, thank you, I got it. [15:58:07] drv, bwalker: https://review.gerrithub.io/#/c/395872/ [16:00:55] jimharris: I'm OK with putting this in if you think it will resolve things... [16:01:05] but we should definitely prioritize fixing the splitting correctly [16:01:45] agreed [16:02:17] pwodkowx, darsto, darsto_: can you guys check this? ^^^^ [16:09:00] jimharris: did you see darsto_'s comment on https://review.gerrithub.io/#/c/393993/ ? [16:58:53] *** Joins: ziyeyang_ (ziyeyang@nat/intel/x-gvjxdcsrlprhdsbu) [17:03:34] *** Quits: lhodev (~Adium@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [17:03:51] *** Joins: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) [17:34:40] *** Quits: ziyeyang_ (ziyeyang@nat/intel/x-gvjxdcsrlprhdsbu) (Ping timeout: 260 seconds) [17:52:45] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.72) [18:09:34] *** Joins: ziyeyang__ (ziyeyang@nat/intel/x-xlivivtbxkipsbto) [18:09:35] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.72) (Remote host closed the connection) [18:12:26] *** Joins: ziyeyang_ (ziyeyang@nat/intel/x-kohyzuanfytfavmj) [18:12:26] *** Quits: ziyeyang__ (ziyeyang@nat/intel/x-xlivivtbxkipsbto) (Remote host closed the connection) [18:25:25] *** Joins: ziyeyang__ (ziyeyang@nat/intel/x-sbiovvnxxkrcjsth) [18:25:26] *** Quits: ziyeyang_ (ziyeyang@nat/intel/x-kohyzuanfytfavmj) (Remote host closed the connection) [19:56:58] *** Quits: bwalker_ (~bwalker@ip70-190-226-244.ph.ph.cox.net) (Quit: Leaving) [22:58:23] *** Quits: ziyeyang__ (ziyeyang@nat/intel/x-sbiovvnxxkrcjsth) (Ping timeout: 248 seconds)