12:07:34 [illumos-gate] 17734 ZFS fsync can trigger ZIL transaction reordering and data corruption -- Andy Fiddaman 12:09:58 nice! 18:24:04 People using my openjdk patches may be interested in the xattrs.patch I've just added for JDK21 and later, which restores extended attribute support 18:35:17 Thanks, ptribble! 18:53:58 Definitely interested ptribble, thanks, it'll be incorporated into next week's OmniOS JDK updates. 19:21:58 ptribble: neat! 19:48:48 Thank you very much, @ptribble. 20:20:13 i don't think there is, but in case i missed it.. is there a function that will atomically update a value as long as it's larger than the current value? 20:20:31 i.e. I want to track a max value amongst threads 20:21:06 (if not, atomic_cas in a loop until the target value is larger than the one we want to replace, or we succeed) 20:21:14 is how I was going to do it.. 20:28:08 There's no primitive that I know of. 20:28:57 ok.. figured it couldn't hurt to ask 21:06:50 jbk: I would keep a per-thread max value and do the max() aggregation on read? 21:13:31 this is in the kernel (sd)... was looking to collect stats on if/when it's throttling requests because the HBA (or fabric for FC) is reporting full... 21:14:07 mostly to see if the queue depth could be too low (since annoyingly SCSI doesn't actually have a way to tell you what the depth is -- at least that I've been able to find) 21:14:19 for things like SSDs 21:23:20 you could do it per-CPU then instead of per-thread 21:59:14 yeah.. i suppose I could just do a mutex as well -- my expectation is that even if we hit this, it shouldn't be in a crticial path...(if the device's queue is full, the overhead of taking a lock -- even a contested one -- is going to be noise compared to the delay in waiting for the queue to drain) 21:59:39 at this point, it's more about gathering data since it's not something easily visible right now... 22:00:00 and it would not surprise me at all if sd.c's values might not be optimal for modern SSDs 22:01:00 just all the other sd stats use atomic updates.. though that probably doesn't matter too much here... 23:27:04 [illumos-gate] 17340 Want IPv6 Fast Path -- Ryan Goodfellow 23:42:34 took a village to get that one across the line 23:48:46 very valuable though! 23:48:55 Thank you for working on it!