13:02:31 mhm 13:03:41 how bad of an idea it would be to use a NVMe stick so that half of it is "another side" of a pool and the rest is divided into four equal-sized parts used as SLOGs for other pools? 13:04:17 those other pools consist mostly of old hard drives 13:24:37 the question would be, what kind of load are you generating with sync mode writes? 13:26:31 because slog will get transaction group log writes on them, so you will have 4 pools pushing those logs on the single dev. 13:28:30 you can use zilstat to get some idea (assuming it is still usable with illumos) 13:34:04 this is just a file server at home. what I'm looking for is better performance when working with source code trees, build trees and the like, and figured this might help with them. 13:34:34 it isn't exactly slow now either, but I got the NVMe for next to nothing and figured I'll put it into the server. 13:35:04 no zilstat in OmniOS :( 13:35:27 man -k zil returns zilch, as the Americans say 13:36:03 well, unless you use zvols, nfs or apps like db systems, you probably have most IO done async. but, it would be good to check 13:36:16 everything happens over NFS and that's why I'm looking at this 13:36:25 https://www.richardelling.com/richard-elling-consulting/scripts-and-programs/zilstat 13:36:45 nice, thank you 13:37:00 I somehow assumed it's an operating system command 13:37:34 "Google Drive can't scan this file for viruses." :D 13:37:53 it would be nice to have it (arcstat is there already) 13:38:01 can I somehow opt for an internet without training wheels 13:42:05 "probe description fbt::zil_lwb_write_start:entry does not match any probes" - hm. dtrace -ln 'fbt::zil*:entry' gives zil_lwb_write_open, zil_lwb_write_done and zil_lwb_write_issue. wonder which would be closer to the original intent - obviously not the "done" one but "open" or "issue"? 13:51:19 zil_lwb_write_issue() starts log block write. 13:53:22 zil_lwb_write_done() does issue DKIOCFLUSHWRITECACHE - that is, the write did land, but it may still be in the cache. zil_lwb_flush_vdevs_done() is telling the lwb is "done". 13:53:43 (from comments in zil.c) 13:55:24 DKIOCFLUSHWRITECACHE is the call which can kill the performance, as you will get them from 4 slog devices and from the data pool itself 18:39:22 thanks - good point, it's open source and this means that the source code can be read :) should've thought of that 18:39:44 but yeah, good point