February 18, 2018 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | >
February 18, 2018 [00:53:52] *** Hivlaher <Hivlaher!~Hivlaher@a8570-adsl4.pck.nerim.net> has quit IRC (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)[01:07:53] *** andy_js <andy_js!~andy@5ec0fdb3.skybroadband.com> has quit IRC (Quit: andy_js)[01:28:53] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has quit IRC (Ping timeout: 255 seconds)[01:33:27] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has joined #openzfs[01:42:30] *** elxa <elxa!~elxa@2a01:5c0:e16e:3b11:89ae:5b09:436e:c0de> has quit IRC (Quit: Leaving)[02:52:57] *** cbreak <cbreak!~cbreak@46-126-120-226.dynamic.hispeed.ch> has quit IRC (Ping timeout: 240 seconds)[02:53:32] *** cbreak <cbreak!~cbreak@46-126-120-226.dynamic.hispeed.ch> has joined #openzfs[02:55:54] *** PMT <PMT!~PMT@pool-98-116-146-216.nycmny.fios.verizon.net> has quit IRC (Quit: leaving)[04:06:25] *** PMT <PMT!~PMT@pool-98-116-146-216.nycmny.fios.verizon.net> has joined #openzfs[04:40:16] *** chrkl_ <chrkl_!~chrkl@p57ADD0D3.dip0.t-ipconnect.de> has joined #openzfs[04:43:28] *** chrkl <chrkl!~chrkl@p4FD143A1.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 265 seconds)[04:43:28] *** chrkl_ is now known as chrkl[06:52:29] *** michaeldexter <michaeldexter!~michaelde@c-73-157-221-98.hsd1.or.comcast.net> has joined #openzfs[07:35:03] *** michaeldexter <michaeldexter!~michaelde@c-73-157-221-98.hsd1.or.comcast.net> has quit IRC (Quit: michaeldexter)[07:55:08] *** Botanic <Botanic!~Botanic@tita/admin/Botanic> has joined #openzfs[08:39:05] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has quit IRC (Ping timeout: 255 seconds)[08:42:32] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has joined #openzfs[09:16:37] *** ptx0 <ptx0!~cheesus_c@unaffiliated/ptx0> has quit IRC (Ping timeout: 260 seconds)[09:24:43] *** zfs <zfs!~zfs@unaffiliated/ptx0> has quit IRC (Read error: Connection reset by peer)[09:30:38] *** ptx0 <ptx0!~cheesus_c@unaffiliated/ptx0> has joined #openzfs[09:31:34] *** zfs <zfs!~zfs@unaffiliated/ptx0> has joined #openzfs[10:30:24] *** andy_js <andy_js!~andy@5ec0fdb3.skybroadband.com> has joined #openzfs[10:57:32] *** Botanic <Botanic!~Botanic@tita/admin/Botanic> has quit IRC (Read error: Connection reset by peer)[11:02:46] *** michaeldexter <michaeldexter!~michaelde@c-73-157-221-98.hsd1.or.comcast.net> has joined #openzfs[11:58:43] *** elxa <elxa!~elxa@2a01:5c0:e16f:74c1:6998:40f:b557:25ae> has joined #openzfs[12:15:05] *** michaeldexter <michaeldexter!~michaelde@c-73-157-221-98.hsd1.or.comcast.net> has quit IRC (Quit: michaeldexter)[13:12:59] *** Izorkin <Izorkin!~Miranda@91.216.72.209> has quit IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)[13:33:50] *** Kurlon <Kurlon!~Kurlon@98.13.72.207> has quit IRC (Remote host closed the connection)[14:10:49] *** Izorkin <Izorkin!~Miranda@91.216.72.209> has joined #openzfs[14:20:55] *** glasspelican <glasspelican!~quassel@ktnron060ww-lp130-04-76-67-126-214.dsl.bell.ca> has quit IRC (Read error: Connection reset by peer)[14:21:49] *** glasspelican <glasspelican!~quassel@ktnron060ww-lp130-04-76-67-126-214.dsl.bell.ca> has joined #openzfs[15:11:57] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has quit IRC (Ping timeout: 255 seconds)[15:14:23] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has joined #openzfs[15:52:23] *** efm <efm!~efm@vpn.tummy.com> has quit IRC (Remote host closed the connection)[15:52:44] *** efm <efm!~efm@vpn.tummy.com> has joined #openzfs[16:04:49] *** efm <efm!~efm@vpn.tummy.com> has quit IRC (Remote host closed the connection)[16:16:45] *** efm <efm!~efm@vpn.tummy.com> has joined #openzfs[16:25:33] *** efm <efm!~efm@vpn.tummy.com> has quit IRC (Read error: Connection reset by peer)[16:26:39] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has quit IRC (Ping timeout: 255 seconds)[16:28:52] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has joined #openzfs[16:40:18] *** efm <efm!~efm@vpn.tummy.com> has joined #openzfs[16:47:22] *** efm <efm!~efm@vpn.tummy.com> has quit IRC (Read error: Connection reset by peer)[16:48:37] *** efm <efm!~efm@vpn.tummy.com> has joined #openzfs[18:24:06] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has quit IRC (Ping timeout: 255 seconds)[18:26:34] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has joined #openzfs[18:31:50] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has quit IRC (Remote host closed the connection)[18:32:06] *** jnollette <jnollette!~jnollette@gateway/tor-sasl/jnollette> has joined #openzfs[18:49:58] <problame> I have a filesystem with 10000 bookmarks. Delete and list -t bookmark take approximately 4 seconds. While I understand that the list needs to buffer the ioctl-response in the kernel, I do not understand why the duration of `zfs destroy foo#bookmark` is dependent on the number of bookmarks. Would anyone be so nice and explain that to me?[18:50:51] <DeHackEd> it shouldn't be. the list of bookmarks is just a hashtable of { bookmarkname => [ guid, creation, createtxg, maybe other fields], anotherbookmark => [ ... ], ... }[18:51:36] <DeHackEd> but being a hashtable I would expect modifications to be somewhere between O(1) and O(log(n)). the main slowdown would be the txg flush that all administrative actions perform[19:09:16] <problame> DeHackEd: well... should I stop my script that deletes the bookmarks to have some way to debug this?[19:10:31] <problame> DeHackEd: The machine runs FreeBSD 10.1-RELEASE - if you have a dtrace script handy that would facilitate debugging, i could run it[19:12:19] <problame> DeHackEd: other theory: the destroys only happen when ZFS takes a new checkpoint (new uberblock), which is every 5s on a system that has practically no other I/O[19:46:40] *** elxa <elxa!~elxa@2a01:5c0:e16f:74c1:6998:40f:b557:25ae> has quit IRC (Quit: Leaving)[19:53:36] *** michaeldexter <michaeldexter!~michaelde@c-73-157-221-98.hsd1.or.comcast.net> has joined #openzfs[20:05:28] <monsted> can do destroy several at once by listing them together on one command line?[20:06:52] <DeHackEd> it probably should. snapshots have a "first%last" range destroy option. and maybe now that channel programs exist it could be done more efficiently in bulk...[20:35:34] <AllanJude> 10.1 is awefully old[20:35:43] <AllanJude> but I don't think bookmarks have changed[20:36:33] <problame> yuck, I mean 11.1-RELEASE[20:36:58] <problame> but afaik I can't specify multiple bookmarks on the command line, nor does the range feature work for bookmarks - right?[20:37:24] *** michaeldexter <michaeldexter!~michaelde@c-73-157-221-98.hsd1.or.comcast.net> has quit IRC (Quit: michaeldexter)[20:37:41] <problame> in any way, this is not really about how to solve my problem of getting rid of the bookmarks, but to find our _why_ destroying bookmarks takes a long time if there are many of them[20:53:43] <DeHackEd> deleting a bookmark SHOULD be faster than deleting a file from a directory when its hardlink count is >= 2[21:01:10] <problame> DeHackEd: yup. I think there is some kind of knee in the curve. I had a shell script running that would delete bookmark by bookmark, and the first few thousand ones took significantly longer than the last few thousands...[21:02:10] <problame> The problem is that I need to clean that machine up _now_, because the zfs list is inacceptably slow.[21:12:42] <problame> another observation: the destroy consumes 100% CPU single-threaded in the kernel for approx 1s[21:14:40] <DeHackEd> really... now that is weird..[21:14:45] <DeHackEd> are you doing destroy -r maybe?[21:14:45] <problame> oncpu flame graph: http://hetzner1.cschwarz.com/cs/zfsbookmark/oncpu.svg[21:14:53] <problame> re destroy -r: no[21:15:10] <DeHackEd> ... wow... strcmp? really?[21:16:20] <problame> well, this is the oncpu flame graph . I look at htop, which updates the UI approx every second. Thus, even though I see 100% CPU for one second, it doesn't mean anything.[21:16:47] <problame> But: zfs list consumes significant amounts of kernel memory with such a huge amount of bookmarks, because - afaik - the ioctl API is not streaming[21:17:01] <problame> => buffers the entire serialized nvlist in the kernel, right?[21:19:06] <problame> so is there a dsl_get_boomarks somewhere in the destroy bookmark path?[21:19:35] <DeHackEd> wow... that really looks like a poor implementation of the userspace interface...[22:18:31] *** Kurlon <Kurlon!~Kurlon@98.13.72.207> has joined #openzfs[22:56:59] *** Botanic <Botanic!~Botanic@tita/admin/Botanic> has joined #openzfs