03:28:39 richlowe: got the *scanf checking enabled as well (much less noise from that). 14:31:22 Errm: https://github.com/openzfs/zfs/pull/14756/files#diff-539674efbce9f51b3f6b2b9c18ecaace3de7999a5c4d40e28d0a1db69bc6f3f2R237 14:31:30 This is normal practice on Illumos installs, is it not? 14:31:48 Is this deadlock mentioned a thing on Illumos? 14:32:20 The FAQ itself seems to indicate that it might be a more Linux specific issue 14:32:43 people have been doing swap on zfs on illumos (and solaris prior to that) for decades 14:32:52 i've not heard of any problems 14:33:13 doesn't mean there may not be any, but if there are, they seem to be rare 14:33:51 I feel like there is an intrinsically greater change of deadlock than using a raw device. 14:34:03 In the case that pages are being ejected to swap because the system is short of memory.. 14:34:28 writing a page to a swap device backed by ZFS is going to require more memory to do 14:34:47 It's why I often see people setting ZFS options like `logbias=throughput` on swap zvols 14:35:13 We have definitely seen deadlocks where the system is so short of memory that it cannot find memory to eject pages to disk 14:35:24 and it's why jclulow added a memory reserve just for this 14:36:44 Or, more precisely, made ZFS use the existing `pageout_reserve` pool. (sorry, misremembered) 14:38:15 illumos 13092 (fenix) 14:38:16 BUG 13092: ZFS I/O pipeline should use the pageout_reserve pool (Closed) 14:38:16 ↳ https://www.illumos.org/issues/13092 | https://code.illumos.org/c/illumos-gate/+/891 14:39:13 though generally if you're paging to swap, you've probably already lost because drives are so much slower these days 14:39:36 I mean yes it makes sense, going through the DMU layer is going to have some memory costs to it, but there are some pretty clear advantages, too 14:40:42 Is that a reference to that strange DISKRPM constant? I often see systems ejecting pages to swap when they need to reclaim memory - usually when I accidentally build too many copies of clang in parallel though 14:40:44 it's definitely an uh oh situation but it's at least a recoverable one sometimes 14:41:17 (although maaaaybe with some of the newer NVMe devices it might actually make more sense again to use it again) 14:42:16 at the very least if it's on a pool, besides the obvious integrity benefits, you get the striped bandwidth from it 14:42:29 You can easily encrypt it too, without having to involve lofi 14:42:39 (fairly easily) 14:42:57 however helpful that bandwidth really is for a half dozen 4k pages that are somewhat disjoint, I dunno 14:43:27 A downside is that you can share a raw swap device with the system dump device, but not a zvol. 14:43:41 Can we trust ZFS encryption yet? The issues page on OpenZFS for encryption related problems make me very nervous about it 14:44:15 not from a cryptographic standpoint but from a "swallowed my data and can't recover" standpoint 14:44:56 I am not aware of any issues, MNX probably have most experience using it. 14:45:12 There's a problematic incompatibility with openzfs though, which I don't think is resolved yet. 14:48:39 yeah i need some time to finish fixing that 14:49:08 I have the core bit of the fix done, it's just wiring up all the pieces to control the behavior 14:49:13 that i haven't finished yet 14:53:02 A lot of the issues revolve around send and receive but there are others as well that make me nervous 14:57:09 14166, 13521, 13491, 12614, 11679 to name a few 15:04:08 yeah, send/recv problems were what delayed encryption support in illumos for quite a while 15:04:46 unfortunately, it was 'well it's not happening to me, so i don't care about it' 15:04:59 until i finally made it happen on ubuntu 15:05:54 [illumos-gate] 15600 SMB2_read Length=0 assertion panic -- Gordon Ross 15:43:58 another thing about zfs swap is that illumos uses a clock-type allocator -- all pages in the swap device get written, so the device ceases to be sparse after one lap of the clock. 15:44:54 wouldn't be a problem *if* the VM system knew how to trim/overwrite freed pages with zeros. 15:56:44 for swap devices, I wonder if sync=disabled would make any difference (since nothing on the swap device is useful after a crash..). Maybe the primarycache/secondarycache should be set to "metadata". 15:56:54 tsoome_: is 15608 suppose to include a change with actually disables the referenced warnings/gags, or is that coming later? 15:57:14 (if later, it would be good to note that in the ticket) 15:57:56 sommerfeld - https://github.com/omniosorg/kayak/blob/master/lib/disk_help.sh#L158-L166 is what omnios does fwiw 15:59:49 hunh. sync=always ? 16:01:29 Yes, interesting 16:02:08 pmooney yes, once we have last one (rtld - because it is one really fragile bit) done, we can drop sgs "global" gags. I'll add note in issue, thanks. 16:02:28 sounds good 16:03:19 tsoome_: If you haven't already, it might make sense to file that "central" ticket (where you intend to actually drop the global gags) and associate these related tickets 16:03:41 That would leave a nice trail for anyone looking at it (now, or in the future) 16:03:43 hm, yes, thats good idea 16:31:04 pmooney: I've heard that sort of thing called an "umbrella" bug/ticket/... 17:37:45 sommerfeld: maybe as a first approximation i don't think it'd be too difficult to try to issue a TRIM for the entire LBA range of a swap device when added 17:38:09 won't help as much if it's getting used a lot 17:38:31 but at least it would start out as empty 17:51:38 in a similar vein, I believe at least on FreeBSD, when adding a disk to a zpool, it also tries to trim the entire range of the device 17:52:47 (of course there are some that at least on enterprise disks, TRIM should never be necessary) 17:54:31 err some that believe 17:55:06 [illumos-gate] 15608 link_audit: clean up warning gags -- Toomas Soome 17:56:18 I've always seen the overprovisioning amounts based more around meeting an expected lifetime vs. guaranteeing a certain I/O rate 17:56:27 so *shrug8 18:01:23 Yeah. ssd is more likely to make better wear-levelling choices when it doesn't think it has to preserve data we don't care about. 20:29:06 sommerfeld: thanks for noticing make -w! life changing. 20:29:30 both for compilation-mode, and also for sneaky nightly.log grepping. 20:29:36 ?? 20:30:02 make -w is definitely awesome. 20:30:43 Don't make us read the source, what does it do? 20:31:26 Lists the directory that you're entering. 20:31:45 `man make` is all you would need to do. Anyway, it prints the current working directory before and after processing, which means if you need to rerun a command for debugging purposes, you no longer need to jump through hoops to figure out what the current working directory is. 20:31:55 I did not see -w in the man page 20:32:21 That needs to be fixed. 20:34:42 that's what sommerfeld is fixing, in fact. 20:46:54 Yes. I also have some patches to nightly and bldenv that make them play nicer with make -w (bldenv: let you set MAKEFLAGS in your env file. nightly: don't interpret the entering/leaving messages as errors and filter them out from stuff that lands in the mail_msg file) 21:23:24 man page fix out for review: https://code.illumos.org/c/illumos-gate/+/2850 21:23:25 → CODE REVIEW 2850: 15654 Document make -w (NEW) | https://www.illumos.org/issues/15654 22:16:23 ahh nice