[00:07:21] *** Quits: baruch (~baruch@31.210.182.176) (Read error: Connection reset by peer) [01:00:28] *** Joins: baruch (~baruch@bzq-82-81-85-138.red.bezeqint.net) [01:49:29] *** Joins: baruch_ (~baruch@bzq-82-81-85-138.red.bezeqint.net) [01:49:52] *** Quits: baruch (~baruch@bzq-82-81-85-138.red.bezeqint.net) (Read error: Connection reset by peer) [05:22:02] *** Quits: baruch_ (~baruch@bzq-82-81-85-138.red.bezeqint.net) (Ping timeout: 260 seconds) [05:38:46] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [06:46:24] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [07:08:18] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [08:37:05] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [08:52:20] in scsi_bdev standard INQUIRY we seem to always report as iSCSI(scsi_bdev.c:730 - the 0x0960), is this intended? [08:53:18] http://www.t10.org/lists/stds.htm [09:38:50] bwalker, if you're still lurking out there, please take a gander at https://review.gerrithub.io/#/c/376276/ [10:32:03] darsto, sure looks intentional :) [11:15:59] bwalker, wrt that last patch ^ after looking at both the superblock and per block clean/dirty states it looks like you define dirty as "needs to be syncd" and something in vol memory as opposed to a state that is persistent that says "I am consistent" or not. So in terms of recovery you need the latter and the patch above is at least part of the solution. If you can shed some light on the semantics of the super and per blob clean flags and power fail/recovery [11:15:59] scenarios that'd be great [11:35:32] *** Joins: vermavis- (vermavis@nat/intel/x-woaxtvbhklyjqfut) [11:37:35] *** Quits: vermavis (~vermavis@192.55.54.36) (*.net *.split) [11:37:37] *** vermavis- is now known as vermavis [11:39:27] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Ping timeout: 260 seconds) [11:42:05] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [12:02:42] So I've got 2 systems each with one of these dudes in them "Chelsio Communications Inc T580-LP-CR Unified Wire Storage Controller" and know little about Linux networking [12:04:10] I believe I have the drivers up and running in both as each side shows Link Detected with ethtool but am not really sure what I need to do next with these things to get the SPDK NVMeOF target up and doing something interesting [12:05:43] I've looked at http://www.spdk.io/doc/nvmf.html but am still not sure on next steps. Willing to take advice from anyone willing to give it... :) [21:55:42] *** Joins: baruch_ (~baruch@31.210.182.176)