[02:12:01] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [04:43:11] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [04:56:20] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [07:01:17] *** Quits: tomzawadzki (~tzawadzk@192.55.55.41) (Ping timeout: 246 seconds) [08:32:45] yeah - I'm not sure you can get an alias to do this [08:32:55] freebsd doesn't have nproc - you can do something like: [08:33:03] sysctl hw.ncpu | awk '{print $NF}' [09:12:28] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [09:24:14] *** Joins: pi_r (~ppelplin@2a02:a31b:8121:e200:d1b0:1c54:4307:bb43) [09:26:24] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [09:32:59] We were talking today about implementing lvol (blobs as bdevs). After some thinking we've got one new idea. [09:34:20] We don't really need blobstore_create/blobstore_destroy rpc calls. We can dynamically create blobstore during first add of logical volume and destroy it when last logical volume is deleted. [09:34:25] What do you think? [09:38:48] i would prefer explicit lvolstore_create/destroy calls [09:39:07] an empty lvolstore is ok [09:42:57] it is really best to break these out into separate calls - then when you create an lvol and it fails, you do not have to guess why it failed (did the lvolstore creation failed? or was it allocating the lvol?) [09:43:36] We can show appropriate error [09:43:42] Do we keep any specific meta information in empty lvolstore? [09:44:25] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [09:44:52] no - but what if I want to create an lvolstore on a bdev and keep it there? if you delete the lvolstore when the last lvol is deleted, now that bdev is free to be used by something else [09:47:09] well actually yes - there will be a guid [09:47:36] if you delete the lvolstore and then recreate it - a different guid will be generated [09:47:57] but we will identify logical volumes by blob guid, not blobstore guid [09:48:45] you mean lvol guid, not lvolstore guid? [09:48:50] blob and blobstore do not have guids [09:48:50] yes [09:49:17] yes, i meant lvol guid, and lvolstore guid :-) [09:49:24] but if you identify the lvol only by an lvol guid, then you have to search all lvols to find that guid [09:49:49] i think its better to use lvolstore guid + blobid [09:49:59] you will have many fewer lvolstores than lvols [09:50:00] its part of lvol name anyway, isn't it? [09:50:34] what is part of lvol name? [09:51:01] lvol guid will be part of lvol name [09:51:29] why do we want an lvol guid? [09:51:34] i'm not following [09:52:13] Well, it's required only if we don't care about lvolstore guid [09:52:15] i guess the real question is - why have the implicit lvolstore operations? [09:52:37] It reduces complexity of using lvol [09:52:58] less RPC calls to do same thing [09:53:12] it would just add one extra RPC call right? [09:53:19] when creating? another one when destroying? [09:53:22] yes [09:53:29] what are the downsides? [09:55:27] when i create a new lvol, how do i specify the lvolstore that i want to create it in? [09:55:40] i think you want to specify the lvolstore guid, not a bdev name [09:57:49] I think there is only one little downside - it increases complexity of using it. You have to care about lvolstore guid, you have to remember about exclicitly creating and destroying lvolstore [09:58:57] but i think trying to hide that complexity made it unusable in real world scenarios [09:58:58] Why not bdev name? You specify it just on adding lvol and you get lvol-guid, which should be uniqe globally [09:59:03] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [10:00:04] because a bdev name can change - for example, i can reload the application and map an nvme device to a different bdev name [10:00:53] but the guid would be written to the disk so no matter how that bdev is named, or even moved to a different system, or accessed remotely instead of locally - we know we have the right lvolstore because we have the right guid [10:03:34] we should design the rpcs for the advanced user - not to make it simple for the newbie user [10:03:36] Ok, I see the point [10:03:57] we can always create rpc clients that hide complexity if really becomes to burdensome [10:04:32] but make some of the operations implicit, it removes control from the advanced user [10:04:46] "but make" => "by making" [10:05:58] Another qestion :-) [10:06:16] What if we want to move some lvols to another lvolstore? [10:06:45] it wouldn't be a "move" as much as a "clone" [10:07:00] Should we still identify them by lvolstore-guid->lvol-guid? That creates some problems [10:07:11] there is no lvol guid [10:07:15] ok [10:07:16] lvolstore guid + blob id [10:07:19] lvol-id [10:07:20] ok [10:07:57] what problems does that create? [10:08:20] So, when such cloning will happend, we change identifier for that lvol, right? [10:09:02] we don't really change the identifier - we create a new lvol that has its own id [10:09:11] right [10:09:35] ok, that answers my question [10:09:39] thanks Jim [10:09:44] np [10:15:04] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [10:34:29] jimharris, yeah thanks that what I tried to alias nproc too and it worked from the shell but not when I run gmake as the isntructions state. it fails on n attempt to call nproc. how are you building? [10:36:40] is it failing in the dpdk submodule build? [10:38:48] one sec, I'll paste it in here [10:39:38] FYI using vagrant box freebsd/FreeBSD-10.3-RELEASE [10:43:41] well, this is slightly different than what I remember from Thu but pretty close :) https://gist.github.com/peluse/7cb0b02c269d4d3779187823a7d490fc [10:46:09] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [10:47:10] building dpdk on freebsd requires a kernel source tree - my guess is that vagrant box doesn't have one [10:47:17] is there a /usr/src directory on that vagrant box? [10:47:33] but that output you shared didn't look at all nproc-related [10:59:38] nope there isn't one. I think when I tired it last time it stopped earlier than that. I'll install the source and try again [11:00:27] so there's definitely a bug in dpdkbuild/Makefile - it needs to use something different to set NPROC when OS=FreeBSD [11:03:13] cool, I'll see if I can get past this thing and will just hardcode that for now, then try something fancy after that [11:03:41] we already check OS type in dpdkbuild/Makefile so you have an easy place to move the NPROC defs there [11:03:50] cool [11:03:58] but the kernel source...not sure about that [11:04:22] well, I'm git'ing it now so we'll see how well the vagrant box matches the tagged release that it says it is [11:04:50] hey, is today a holiday or some shit like that? [11:05:23] * peluse was wondering why the kids weren't in school today... [11:05:24] yeah - i came into the office today since i'm out thurs this week through end of next week - got some sweet parking [11:05:36] nice! [11:47:20] *** Quits: pi_r (~ppelplin@2a02:a31b:8121:e200:d1b0:1c54:4307:bb43) (Quit: Leaving) [12:05:59] OK, builds with the proper freebsd src in /usr/src and with NPROCS hardcoded in the Makefile. Will go drink beer now and fix up the makefile later... Happy Memorial Day!! [12:06:06] PS: unitests pass also :) [13:33:56] bwalker, drv: build pool seems to be down - or at least the master isn't checking for new patches [15:02:23] jimharris, FYI pushed the makefile tweak [15:03:38] hey is it me or is the SPDK reviewers group not there anymore? [15:05:14] on gerrithub? [15:13:40] yeah [15:13:51] we didn't move it over to gerrithub [15:14:00] wait, what? [15:14:16] when I push a patch now I have to add reviewers yes? [15:14:20] no [15:14:36] i have my dashboard to just look for open spdk patches [15:14:58] oh, OK. even better than. i didn't catch that in the memo :) [15:15:29] i mean if you want to add reviewers to your patch, that's fine, but at least bwalker, drv and myself aren't really waiting to be added as a reviewer [15:15:51] so hey for stuff like "./configure" I seem to have to install bash first (freebsd). Is that how its supposed to be? [15:15:57] i.e. if there is a non-maintainer or two you specifically want to look at a patch [15:16:02] yeah wrt reviewers that how I think it should be [15:16:29] yeah - that is normal [15:16:32] someone should only add a reviewer if that have a specific desire for that person to look for some reason and not as a general rule [15:16:38] ok, thanks [15:16:39] bash is not part of freebsd base system [15:17:15] we (maintainers) are also planning to reserve the "assignee" field for maintainer use - i.e. we want to delegate an initial review to a non-maintainer [15:17:19] so I'm adding installation of stuff like that in the readme, I will udpate the freebsd part of it here shortly (theres an open reiew with fedora and ubuntu stuff udpated already) [15:17:32] good cal [15:17:34] call [15:18:10] and then we will also use it to assign ourselves to specific reviews - i.e. i look at some review and say "really drv needs to drive this one to closure" [15:18:22] ya [16:44:06] *** Joins: tsuyoshi (b42b2067@gateway/web/freenode/ip.180.43.32.103) [18:42:58] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [20:55:28] *** Quits: peluse (~peluse@192.55.54.44) (Read error: Connection reset by peer) [20:56:38] *** Joins: peluse (~peluse@192.55.54.44)