[00:09:12] *** Quits: tomzawadzki (~tomzawadz@134.134.139.76) (Quit: Leaving) [00:13:08] *** Joins: tomzawadzki (~tomzawadz@134.134.139.76) [01:57:35] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [02:16:07] *** Joins: tkulasek (86bfdc47@gateway/web/freenode/ip.134.191.220.71) [05:53:14] *** Quits: tkulasek (86bfdc47@gateway/web/freenode/ip.134.191.220.71) (Ping timeout: 260 seconds) [06:08:05] *** Quits: tomzawadzki (~tomzawadz@134.134.139.76) (Ping timeout: 240 seconds) [06:43:47] drv: worldtimebuddy.com can help us with this challenge :) [06:44:58] like for this Thu's meeting: https://www.worldtimebuddy.com/?qm=1&lid=100,12,207,1796236&h=12&date=2018-2-22&sln=17-18 [07:35:35] Hi folks [07:35:36] I have a question regarding exposing blobstore snapshot/clones relationships to upper layers, like lvol. [07:35:50] As we discussed before, we should disallow implicit actions (like delete) on snapshots that have dependant blobs (clones). [07:36:23] So, if user wants to delete a snapshot, first has to either delete or inflate a clone. [07:36:42] The question is, how is he going to know which clones he should inflate/delete first? [07:36:53] Our idea is to expose is to show than relationshpis in get_bdevs rpc call. [07:37:23] To achieve this, we need to extend blobstore API to expose that relationships to upper layers. What do you think about this? [08:00:18] *** Joins: tkulasek (86bfdc49@gateway/web/freenode/ip.134.191.220.73) [08:35:00] *** Joins: Param (~Param@157.49.22.234) [08:35:19] Hi Benjamin.. [08:38:52] ppelplin, yeah I think that was implied - either API exposure or specific information in the error message on the attempted delete indicating which blob is holding things up. That would be the extent of SPDK's involvement though, the app would have to take all the next steps on its own [08:39:10] *** Quits: Param (~Param@157.49.22.234) (Read error: No route to host) [08:39:28] and I think probably in the error message might the most sense but that's just a quick thought [08:43:10] *** Joins: Param (~Param@106.206.51.101) [08:44:16] *** Joins: tomzawadzki (~tomzawadz@192.55.54.42) [09:06:45] peluse: at this time error message is just errno, and snapshot deletion can be held up by multiple clones. Error message might get quite elaborate if it was extended, especially that we already return EBUSY on blob delete if that blob is still opened. [09:07:32] i think there are two parts probably [09:07:43] Hi All, I would start contributing to SPDK as an individual.. I have been using SPDK for quite sometime and aware of modules/libraries like NVMe,NVMe0F,iSCSI,reactors,.. [09:07:56] 1) extend blobstore API to get relationships between clones and snapshots [09:08:04] So can you suggest me which one I can start [09:08:39] maybe we can track relationships on lvol layer starting on creation clones/lvols? This way we won't need new API [09:09:06] Param: it depends what you want to achieve? [09:10:15] 2) modify lvol bdev layer to add this information in its dump_config_json routine [09:10:16] mszwed: this works for particular run of SPDK when lvols are created. Without separate blobstore api calls, we would have to persist that in lvol xattrs [09:10:41] blobstore will build this information when it loads the blobstore [09:10:47] mszewd: This results in duplicate information (we need to have it on blobstore) [09:10:53] we just need an API to get the info [09:11:03] Param: welcome to #spdk [09:11:13] tomzawadzki: yeah... duplication is not that good... [09:11:35] Param: there are some additional NVMe commands that we need to emulate for the NVMe-oF target [09:12:01] jimharris: Sure I would like to work on that. [09:12:07] here is the Trello board: https://trello.com/b/G2f3dVcs/nvme-of [09:12:53] jimharris: yup, this is what ppelplin had in mind. Just wanted to confirm before we start adding new API calls willy nilly. [09:13:18] drv: can you recommend one of the NVMe-oF cards that Param could get started on? [09:14:04] *** Quits: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 260 seconds) [09:14:32] Sure. That would be good if you suggest which one I should start working on [09:14:46] implementing the Supported Command Effects log page might be a nice place to start, if that sounds interesting: https://trello.com/c/nasK6aQn [09:15:12] it is fairly self-contained and doesn't require anything too tricky [09:15:54] but of course you're free to pick up anything you like :) [09:15:55] jimharris: What in regards to other properties currently not exposed from blobs ? thin_provisioned and read_only can be set but not read later on outside of blobstore [09:19:18] sure drv. I would look into it. For further clarifications of the card can I start directly commenting on the card. Can I add usesr the comment should be notified to ? [09:19:36] *to the comment [09:23:04] *** Joins: lhodev (~Adium@inet-hqmc05-o.oracle.com) [09:28:32] Hey folks. I just rec'd Nathan's email announcing the recent initiation of employing Twitter for sharing SPDK info. Trying to get a handle on this. There's the SPDK mailing list and this, the SPDK IRC channel, and now @SPDKProject (and @DPDKProject) on Twitter? Is this IRC channel being deprecated in favor of Twitter? [09:30:12] lhodev, no not at all. Twitter is just another means of comm but I don't it ever being used to technical discussion. Its more about "spreading the word" [10:04:42] *** Quits: tomzawadzki (~tomzawadz@192.55.54.42) (Ping timeout: 260 seconds) [10:06:25] *** Quits: tkulasek (86bfdc49@gateway/web/freenode/ip.134.191.220.73) (Ping timeout: 260 seconds) [10:30:32] Param: sure, you can add comments on the card if you want to discuss the design or ask questions [10:30:42] and you can add folks to the card too if you want their input [10:45:26] tomzawadzki: yes - we should have an API for those as well (thin provision, read only) [10:47:11] drv: re: spdk_get_thread(), maybe we could have an ifdef in io_channel.c around a thread-local spdk_thread pointer [10:47:30] yeah, if that makes a significant perf difference, we could consider it [10:47:31] then _get_thread() can also have the ifdef and return the thread local variable [11:35:18] *** Quits: Param (~Param@106.206.51.101) (Read error: Connection reset by peer) [11:37:56] *** Joins: Param (~Param@157.49.74.102) [11:43:14] *** Quits: Param (~Param@157.49.74.102) (Read error: Connection reset by peer) [11:48:01] *** Joins: Param (~Param@106.206.51.101) [11:49:36] *** Quits: sethhowe (~sethhowe@192.55.54.42) (Remote host closed the connection) [11:51:58] *** Joins: sethhowe (~sethhowe@134.134.139.75) [12:23:38] jimharris: like we were talking about earlier, when ASAN is enabled, some of the lvol tests fail (see: http://spdk.intel.com/public/spdk/builds/release/master/4361/fedora-08/build.log). I was able to narrow the failure down to the test cases 700 and 701. [12:26:45] ok - do you need both or does one of the other (plus 10000) suffice? [12:27:55] *** Quits: sethhowe (~sethhowe@134.134.139.75) (Remote host closed the connection) [12:34:24] *** Joins: sethhowe (~sethhowe@192.55.54.42) [12:34:43] one or the other [13:03:50] *** Parts: Param (~Param@106.206.51.101) () [13:24:10] *** Quits: sethhowe (~sethhowe@192.55.54.42) (Remote host closed the connection) [13:27:14] hi guys, we using Vhost to serve a 2.4 TB disk to a VM, we format the disk with mkfs.ext4 and then run and bandwidth test using dd [13:27:18] dd if=/dev/zero of=test.out3 bs=1M count=1024 [13:27:38] the first time the test runs fast [13:27:51] but the performance drops by about 10x [13:28:29] dd if=/dev/zero of=test.out bs=1M count=1024 [13:28:30] 1024+0 records in [13:28:30] 1024+0 records out [13:28:30] 1073741824 bytes (1.1 GB) copied, 0.830099 s, 1.3 GB/s [13:28:30] [root@iwarp-dn01 data]# dd if=/dev/zero of=test.out bs=1M count=1024 [13:28:31] 1024+0 records in [13:28:32] 1024+0 records out [13:28:34] 1073741824 bytes (1.1 GB) copied, 11.9247 s, 90.0 MB/s [13:30:15] when we write to a different file name the performance is back up to 1.3 GB/s the first time and then drops again to 90 MB/s [13:34:28] any ideas why the performance drops on subsequent runs [13:35:46] if you are writing to a filesystem, presumably there is caching involved [13:35:49] jkkariu: could it be some OS caching involved (?) [13:36:06] 1 GB is plenty small enough that it could easily fit into RAM and not need to write to disk at all during the benchmark [13:36:23] you probably want oflag=direct at least [13:36:48] also, AFAIR pwodkowx mentioned a while ago that dd is slow by design [13:37:07] it would be interesting to see dd results directly to the block device (without fs) [13:37:08] it uses iodepth==1 [13:37:33] yeah, it won't be great, but you should be able to get fairly decent bandwidth with large I/O size like 1M [13:38:02] you could try cat & pipe to copy the file [13:43:09] I would first try benchmarking the block device without a filesystem to simplify things [13:44:01] e.g. dd if=/dev/zero of=/dev/ bs=1M count=1024 oflag=direct [13:44:25] thanks we will try [13:44:26] that should eliminate any caching and filesystem interference [13:44:39] if that is fast but the fs is slow, then there may be something else going on [13:45:39] if you want to do fs testing, it would probably be best to add oflag=fsync to get a fair result (all data will get flushed before dd exits) [13:46:19] we did dd without the filesystem and the performance is consistently around 1.8 GB/s [13:46:24] sorry, fsync is a conv option, not oflag [13:46:44] we ran it a couple of times and the performance did not drop [13:46:59] ok, that's good - that means the underlying block path is fast [13:47:06] yes [13:47:15] so maybe the filesystem is issuing discards or flushes or something [15:45:25] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [16:30:40] in python script, currently for example about chap_disable, 0 or 1 must be specified in CLI. [16:31:26] after supporting store_true, it will be changed to that if --chap-disable is specified, the value is set to True ? [16:31:42] if --chap-disable is omitted, the value is set to False? [16:31:56] this spec change is allowed, do you think? [16:36:05] Shuhei: I think that makes more sense than the current behavior [16:36:13] maybe --disable-chap would be clearer, though [16:36:58] I guess we should make it consistent with the RPC parameter naming, so whatever we are using there should be OK [16:37:53] Hi Daniel, Thank you, I got it. I'll check the name of parameters. [22:39:44] *** Joins: Param (~Param@157.49.15.180) [22:46:37] *** Quits: Param (~Param@157.49.15.180) (Quit: Param) [23:25:47] *** Joins: tomzawadzki (~tomzawadz@192.55.54.42) [23:30:14] *** Joins: Param (~Param@106.201.127.150) [23:35:34] *** Quits: tomzawadzki (~tomzawadz@192.55.54.42) (Remote host closed the connection) [23:39:21] *** Joins: tomzawadzki (tomzawadzk@nat/intel/x-qbdbeorqtxintiiw)