[00:53:26] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.78) (Quit: Leaving) [06:51:48] *** Joins: d4ydr34m (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) [06:52:05] *** Quits: d4ydr34m (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) (Client Quit) [06:52:38] *** Joins: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) [09:05:12] Hello, New to the channel. I am currently working with the SPDK and and am very interested in potentially using the blobstore aspect. Being very new and with the very minimal documentation/examples. Where is the best place to start? Currently have spdk working with NVME drives, just would really love to utilize the blob store functionality [09:13:54] hi nKumar, the simplest way to use the blob store is probably the blob_bdev wrapper - this will let you open any SPDK bdev (including NVMe) as a blob store device [09:14:24] got it, thanks! [09:14:33] then you can use the blob.h APIs on that spdk_bs_dev that you get from spdk_bdev_create_bs_dev() [09:14:50] shot in the dark, but do you know of any examples out there that I should look at? [09:15:56] unfortunately, I don't think we have any good simple examples of just using the blob store [09:16:08] most of them actually use the blobfs library, which is another layer on top of blob store [09:16:45] you can at least see how e.g. test/lib/blobfs/mkfs/mkfs.c uses spdk_bdev_create_bs_dev() to initialize the bs_dev [09:17:13] awesome, thanks! [09:20:28] I did notice some mention of blobstore on the roadmap. hopefully it an implementation of it will be included in the next release! Very useful functionality for a variety of projects [09:50:31] *** Quits: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) [09:51:12] *** Joins: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) [10:07:08] *** Quits: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) [10:12:29] jimharris: when you get a chance, please review the GPT series (at least the first patch, which is a bug fix): https://review.gerrithub.io/#/c/368606/ [10:48:15] *** Joins: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) [10:50:36] *** Quits: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) (Client Quit) [10:50:46] *** Joins: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) [10:58:46] *** Quits: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) [11:00:42] *** Joins: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) [12:15:10] *** Quits: nKumar (2658e3c4@gateway/web/cgi-irc/kiwiirc.com/ip.38.88.227.196) (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) [12:17:37] drv, jimharris FYI you had both +2'd this before but it needed a rebase before merge, its ready now. https://review.gerrithub.io/#/c/368208/ [12:47:52] drv, i fixed that x however the hell that happened! [12:49:36] it's pretty easy to get mixed up in git's textual two-way merge representation [12:50:11] sethhowe, you there? [12:50:48] drv, I didn't even use that. Just vi, saw the <<<< markers and deleted the 5 LOC that were wrong. Strange [12:51:47] i guess i could have fat fingered the esc x sequence to quit vi if the cursor happened to be on the X... [12:52:43] well, the ExIT was that way in an earlier rev, but we merged a commit to fix it [12:52:59] so you probably just picked the other line when resolving the merge conflict [12:53:29] drv, ahh, that explains it. thought i was losing it! [13:12:04] peluse just got back from lunch. [13:12:43] sethhowe, no prob. was jsut going to ask if you had seen this before running hotplug.sh [13:12:44] + sshpass -p intel ssh -o PubkeyAuthentication=no -o StrictHostKeyChecking=no -p 10022 root@localhost 'echo ready' [13:12:44] ssh_exchange_identification: read: Connection reset by peer [13:13:12] I might have the wrong image, grabbing fedora24.img now - I had the one with new in the name somewhere [13:16:39] I have never run into that issue with the nvme hotplug tests. [13:17:28] figures :) [13:17:58] I'm probably 90 min from the copy finishing, will let ya know how it goes... [13:26:06] ok, the only other thing that I can think after you get the image downloaded is that in the qemu command, we call enable-kvm. If you don't have that functionality enabled, then the vm may not be booting properly. [13:27:26] OK, will see how it goes and go from there. thanks [15:41:45] anyone ever had CI fail something on valgrind but not locally when run (w/valgrind)? [15:48:04] I tend to run using asan instead of valgrind [15:48:33] locally at least [15:48:58] and I've never had a run that passed asan but then failed valgrind in CI [15:49:15] it's probably possible, but never happened for me [15:54:25] peluse: are you running valgrind the same way as the pool? (valgrind --leak-check=full) [15:54:40] bwalker, yeah its happening to me of course :) [15:54:51] drv, not sure I just set the var valgrind and ran [15:54:56] but I can check [15:54:57] ok, that should be the same [15:55:48] my failure might be a case where I have to check in a valgrind error suppression as well. Maybe, will see. Need to dig in a little more [15:57:01] wow, I'm using valgrind 3.11.0 and the CI system I'm looking at is using 2.2.0 [15:57:37] which system is that? maybe it needs an update [15:57:57] wkb-fedora-03 [15:58:09] I can try and downgrade my local one to see if it fails [15:58:35] that one says "Using Valgrind-3.12.0" in the log [15:59:30] oh shit, I was looking at a tab pointed to readme with an example that looked just like our log :) [15:59:49] yeah I see 3.12 now in the log [15:59:56] I'll try and *upgrade* mine then :) [16:00:52] looks like the machine running ASan rather than valgrind also caught the same error: https://ci.spdk.io/builds/review/a43a4b441ddcd6765d09734e82b5136ed7776272.1499720606/vm-fedora-01/build.log [16:01:45] so you can try that if it's easier than trying to upgrade valgrind [16:03:51] upgrading now. I don't think its a real error is the thing, I'm faking one of our malloc calls and its barfing on that but first I need to repro it here before I can say much about it... [16:05:31] it looks like you're just leaking the buffers from the passing test cases on lines 142 and 155 in nvme_ut.c [16:06:00] or more specifically leaking the request objects, not "buffer" [16:06:46] ahhh, OK. where do you see req objects and not buffers? [16:06:51] er, scratch that last statement [16:06:57] it is actually the user copy buffer that is leaking [16:07:09] inside nvme_allocate_request_user_copy(), it calls spdk_dma_zmalloc() [16:07:45] yeah, that's the one I'm faking in the last part of this test [16:08:07] I don't reset the global to turn it back "on" again so figured that might be it but wanted to repro it before taking shots at it on CI [16:08:32] right, but for the previous ones, where you haven't set spdk_dma_zmalloc to fail (return NULL), it actually calls through to spdk_dma_malloc() [16:08:40] I upgraded to 3.13 and it still passes for me lcoallt [16:08:50] its supsoed to on the rpevious ones [16:09:01] so you need to spdk_dma_free() those buffers [16:09:33] oh shit [16:09:56] so nothing to do with the faking, just spent too much time recently in managed languages :( [16:10:07] thanks drv [16:10:20] it's a little bit tricky to follow, but normally nvme_user_copy_cmd_complete() will do the spdk_dma_free() [16:10:34] which is set up as the completion for requests allocated by nvme_allocate_request_user_copy() [16:10:46] yeah, I should have seen it though. missed the forest for the trees on that one [16:10:53] so maybe you want to call the callback from the unit test to get coverage on that too [16:10:58] (or just add the spdk_dma_free() by hand) [16:11:14] I'll just free by hand [16:11:28] strange that my valgrind didn't catch that though [16:11:59] if you're running unittest.sh manually, you need to do something like valgrind='valgrind --leak-check=full --exit-errorcode=2' ./unittest.sh [16:12:03] to match what the autobuild script does [16:14:24] jimharris: are we good to go on https://review.gerrithub.io/#/c/365808/ ? (despite your review comment, you still have it at +2) [16:16:17] drv, OK thanks. I'll push a patch to make it easy to run valgrind locally the right way [16:16:24] ok [16:16:36] after I fix this other thing... :) [16:16:41] i'm fine with it - we can add the timing checks later [16:16:48] also, we should probably set the dma_malloc mock state to a known value at the top of the test function [16:17:00] otherwise it might get some leftover state from other tests later [16:17:26] drv, yeah. I'll set it back to PT at the end also [16:19:24] yeah, that's probably better, actually - that way, functions that don't twiddle with the mock stuff at all get the defaults without having to do anything [16:19:39] (assuming we remember to clean up at the end of every function that changes the mock values) [16:20:22] drv, actually I'll not set it at the top, just at the end. Otherwise we set a precedent that we need to set really everything at the start of every function. We should assume everything is correct going in and when someone adds a new UT they'll find out pretty quick if its not [16:21:23] right [16:25:56] *** Quits: sethhowe (~sethhowe@192.55.54.42) (Remote host closed the connection) [16:27:29] *** Joins: sethhowe (~sethhowe@192.55.54.42) [16:31:01] *** Quits: sethhowe (~sethhowe@192.55.54.42) (Client Quit) [20:27:17] *** Joins: anna__ (c0372e26@gateway/web/freenode/ip.192.55.46.38) [20:29:53] *** Quits: anna__ (c0372e26@gateway/web/freenode/ip.192.55.46.38) (Client Quit) [20:30:50] *** Joins: anna__ (c0372e26@gateway/web/freenode/ip.192.55.46.38) [21:07:39] sethhowe, that issue earlier was indeed a bogus test image [21:08:42] but my hotplug tests fail, will look into more in the morning... [23:51:20] *** Quits: anna__ (c0372e26@gateway/web/freenode/ip.192.55.46.38) (Ping timeout: 260 seconds)