[00:56:01] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [05:32:46] *** Quits: sethhowe (~sethhowe@192.55.55.41) (*.net *.split) [05:32:46] *** Quits: vermavis (vermavis@nat/intel/x-rrshazolzutaqpep) (*.net *.split) [05:33:06] *** Joins: sethhowe (~sethhowe@192.55.55.41) [05:33:14] *** Joins: vermavis- (~vermavis@192.55.54.36) [05:33:38] *** vermavis- is now known as vermavis [07:56:29] *** Joins: peluse_ (~peluse___@2600:8800:140a:ae18:f8fd:8de3:c2bb:7d81) [08:02:13] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [08:04:47] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [09:11:49] *** Joins: lhodev (~Adium@inet-hqmc07-o.oracle.com) [09:15:33] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [10:07:30] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [10:33:50] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [10:42:09] jimharris, bwalker, et al - some thoughts on lvol design: [10:42:21] I like the idea of using UUIDs, but I just had a thought [10:42:42] *** Parts: lhodev (~Adium@inet-hqmc07-o.oracle.com) () [10:42:44] what if we make the fields that are currently UUIDs strings instead, and then let the user use e.g. uuidgen command line tool if they want to use UUIDs [10:42:55] that would mean we don't need to depend on the uuid library [10:44:10] also, I think it would be a good idea to let the user specify a name when creating a lvol that will be used as its bdev name, and store it as an xattr so it's persistent [10:45:12] the idea is to make sure each lvolstore is unique [10:46:06] I think picking a friendly name for the bdev is OK but I'm not sure about persisting it as an xattr [10:46:38] how do you guarantee uniqueness for the bdev names? [10:47:18] we can just make sure the name doesn't already exist (spdk_bdev_get_by_name()) [10:47:51] if the user creates two lvolstores with conflicting bdev names, that's their own problem [10:48:05] if an SSD gets moved between systems? [10:48:22] we could still prefix the name of the lvolstore + lvol name to make it unique as long as the lvolstore name (e.g. uuid) is unique [10:49:09] so if the user uses uuidgen to make the lvolstore name, the bdev names should always be unique even across systems [10:49:31] i would like to change the lvol part of the name to use the blobid as hex and not decimal [10:49:34] what's the scope of an lvolstore? Is it something that consumes 1 blobstore and then you have lvols on top 1:1 for bdevs which are 1:1 with blobs for that system? [10:49:52] then it will show up as something like 1000000001 instead of whatever 0x100000001 is in hex [10:49:57] peluse_: right [10:49:58] sorry - in decimal [10:50:30] jimharris, why do bdev names need to be unique across systems (do we have tools that require that)? [10:50:39] I feel like either way, numeric bdev names are pretty unfriendly - it's not like GPT where there's a small set of partition numbers [10:51:09] I'm ok with friendly bdev names - I just don't think we should persist them [10:51:17] well, then what do we call the bdevs when you start up again? [10:51:35] similar to what we do with nvme today [10:51:49] ok, so you'd have to manually add each lvol -> bdev mapping to a config file [10:52:11] you wouldn't have to - we could have it pick an available name/index if one wasn't specified [10:52:24] Lvol0, Lvol1, etc. [10:52:43] get_bdev rpc can return underlying details on it [10:54:01] alright, that's probably fine... I'd still like to avoid the uuid dependency if at all possible, though [10:54:34] what's your heartburn about the uuid dependency? [10:54:52] you don't like uuids? or you want to remove a library dependency? [10:56:32] remove the library dependency [10:56:44] I mean, it's not the end of the world, but it's a new required dependency for no good reason [10:58:04] I'm open to alternatives - but I think guaranteeing uniqueness for logical volume stores is a good idea if we start looking at SPDK in a scale-out context [10:58:33] (I'm interpreting "no good reason" as not agreeing that uniqueness here is important) [11:01:19] alright, I'll review the patch with the assumption that we will use libuuid for now [11:08:22] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [11:08:39] peluse_ the bdev names don't need to be unique across systems [11:09:12] the bdev name is just used as a generic name that can be used to bind that bdev to an upper layer service like vhost, nvme-of or iscsi [11:09:58] i was concerned about persisting a bdev name for a logical volume, because then if the SSD containing its lvolstore moves, you could end up with bdev name conflicts [11:17:52] got it, thanks [11:25:37] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [12:12:28] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [13:02:28] *** Quits: guerby (~guerby@april/board/guerby) (Ping timeout: 240 seconds) [13:04:41] *** Joins: guerby (~guerby@ip165.tetaneutral.net) [13:04:41] *** Quits: guerby (~guerby@ip165.tetaneutral.net) (Changing host) [13:04:41] *** Joins: guerby (~guerby@april/board/guerby) [13:25:01] *** Joins: guerby_ (~guerby@ip165.tetaneutral.net) [13:25:22] *** Quits: guerby (~guerby@april/board/guerby) (Remote host closed the connection) [13:38:21] *** guerby_ is now known as guerby [13:39:10] *** Quits: guerby (~guerby@ip165.tetaneutral.net) (Changing host) [13:39:10] *** Joins: guerby (~guerby@april/board/guerby) [16:31:40] hmm, one of the vhost intermittent failures I just got looks slightly different than usual: https://ci.spdk.io/builds/review/70d56289efec6a507864c13078d602a8ad95bbe9.1503702920/fedora-08/build.log [16:31:59] this has some "bdev_nvme.c:1248:bdev_nvme_queue_cmd: *ERROR*: readv failed: rc = -12" (ENOMEM) [16:36:57] is this just because we are using a split vbdev and submitting more total I/O than the underlying NVMe queue depth?