00:43:56 trying for put a partition on a big disk... 00:44:16 mklabel gpt is seg-faulting 01:10:44 downtowhippie: What is mklabel 05:04:22 putting a gpt on a disk 05:09:06 trying to put a filesystem on a new WD Ultrastart HC560 05:09:06 run parted, subcommand mklabel gpt - segfault 05:22:54 nevermind - I was doing it wrong 07:13:23 could be yjftsjthsd3_ is spamming the channel? 17:09:09 jclulow: looks like bugs.illumos.org is hanging 17:10:01 Good morning to everyone except Ruby and papertigers :P 17:11:18 thanks! :D 18:03:10 .oO 18:41:12 Someone temporarily ban neuroserve please. 18:41:36 tsoome_: Can you do temporary bans? 18:42:07 I have no privs on channel 18:42:53 I apparently can, but I can't see what you're complaining about 18:43:29 richlowe: You probably have join/quit messages disabled. neuroserve's client keeps joining and leaving the channel, likely due to a connectivity problem. 18:43:47 I do, but also that means I don't see neuroserve right now to do anything about it. 18:43:51 because I guess they left 18:44:06 richlowe: You can message chanserv to do a temporary ban. 18:44:50 they're rejoining approx every 15 seconds and immediately leaving (Excess Flood) 18:45:01 only if I see a host mask or something. 18:45:21 neuroserve (~toens⊙iupvd) has joined 18:45:39 +b *!*@ip-178-202-219-087.um47.pools.vodafone-ip.de 18:45:52 helps if I can type 18:45:56 This is the command: /msg chanserv akick #illumos add neuroserve !T 1440 Fix your IRC client so it stops doing join/quit cycles. 18:46:10 eh, what I did works too, I'll just turn it off in a bit 18:46:16 Alright. 18:46:36 if it's Excess Flood they're doing _something_ they're gonna regret anyway. 19:06:11 As a heads up, the race conditions fixed in these PRs likely apply to illumos and the PRs could use reviewers: https://github.com/openzfs/zfs/pull/14514 https://github.com/openzfs/zfs/pull/14519 19:09:48 One will allow zil_commit() to operate concurrently with zil_suspend() when the thread doing zil_commit is delayed long enough that zil_suspend()'s protection against concurrent zil commits will not protect against the zil_commit() from the past. If you are lucky, an VERIFY will trip. If you are unlucky, you are in undefined behavior territory. The other will deadlock when ZIL has outstanding IO and a pool 19:09:54 suspends, such that zpool clear will hang. 19:12:08 The first was detected by the Windows port. I suspect that it is difficult to trigger on UNIX/UNIX-like systems because of the fair scheduler behavior. The second was detected by a test cycle that stressed ZIL and caused the pool to suspend by powering off drives that we are doing at Klara Systems. 19:48:05 let me know if that didn't stall him out 20:10:37 seems to be working so far 20:32:55 apparently this is a semi-regular thing, so if it happens again, do let me know and we can make it longer and whatever. 20:33:11 I might even remember the akick thing ryao showed me 20:49:19 richlowe: That is the standard way that this is handled in other channels if I recall correctly, although I have not had to do it in channels where I am a channel op in many years. I suggest keeping the command in a text file in your home directory. :) 20:50:15 You can also just message chanserv to ask it how to do things. It has been so long since I last used it that I had to do `/msg chanserv help` and /msg chanserv help akick` to look it up. 20:50:43 Coincidentally, `/msg chanserv flags #illumos` will tell you who has op privileges. I remembered that after my first guess turned out to be wrong. 22:30:09 Another reliability fix that should be relevant to illumos and needs reviewers: https://github.com/openzfs/zfs/pull/14532 22:30:55 It fixes a potential violation of the Single UNIX Specification where fsync() promises data is on long term storage, but it is not due to an unexpected error. 22:31:49 If the kernel is built with assertions, the assertion will trip, but a build without assertions will just violate the SUS should this happen. 22:34:57 huh 22:36:44 tsoome_: Currently, the code will always return success via fsync(). It is supposed to either do it either successfully writing to ZIL or waiting on txg_wait_sync(). If any error that is not EIO, ENOENT, EEXIST or EALREADY is received from ->zl_get_data(), it will do neither. 22:38:28 It looks like this bug has been in the code since 2006, although back then, it did not handle EIO: https://github.com/illumos/illumos-gate/commit/c5c6ffa0498b9c8555798756141b4a3061a138c1 22:48:28 [illumos-gate] 15415 Add GCC 10 runtime to pkgdepend exceptions -- Toomas Soome