00:12:42 <richlowe> I guess it is here, too
00:13:50 <richlowe> I guess I have exactly the setup you do, except for a v. b
00:13:56 <richlowe> and it working
00:13:58 <richlowe> :\
00:14:14 <richlowe> (none of it at all reflected in eeprom(8))
00:14:26 <richlowe> but /system/boot/environment agrees with it
04:13:09 <tozhu> hello all, for ZFS on illumos, when create the zpool and zfs, is it 4k aligned with default command, such as zpool create zones c0t0d0 c0t0d1 , need the -o option with ashift parameter ?
04:13:48 <tozhu> I read some docs, it is required on Linux, I’m not sure if it’s required too on illumos/smartos
04:13:56 <tozhu> best wishes for the answer
05:17:59 <jclulow> tozhu: If your disks advertise themselves as having 4k blocks, we'll create a 4k block sized pool by default; i.e., ashift=12
05:19:35 <tozhu> jclulow: Thank you for the response, I mean I don’t need to type ‘ashift=12’ when run ‘zpool create’, it it create automatially with aligned?
05:20:07 <jclulow> If your disks advertise themselves as having 4k blocks, then yes, it will be created with 4k blocks automatically
05:20:28 <jclulow> If not, then you would have to override
05:20:52 <tozhu> okay, got it, Thank you very much for the answer
05:21:43 <jclulow> You are most welcome!
05:21:54 <tsoome> jclulow does ttyb exists?
05:22:19 <jclulow> yes, if I 'date >/dev/term/b' it pops out on the console.  Indeed, on much older illumos bits, the console worked correctly!
05:23:17 <tsoome> on loader prompt, is console=ttyb ?
05:23:56 <jclulow> I don't see the loader prompt
05:24:19 <tsoome> I mean, if you end up with console=text, it means that either the value is overwritten in loader or dboot/locore
05:24:28 <jclulow> right
05:25:08 <tsoome> unless it fails to set it to ttyb in first place...
05:25:22 <jclulow> jclulow@astrid ~ $ tr '\0' '\n' < /system/boot/environment | grep ^console
05:25:24 <jclulow> console=text,ttya
05:25:30 <jclulow> I guess it's probably setting it to that!
05:25:35 <jclulow> Despite what I told it to use haha
05:26:41 <tsoome> ok text,ttya means two things -- first, kernel will pick first item from list, thats why you get text, and secondly, for some reason, the loader does not appear to see ttyb
05:26:54 <tsoome> does environment list ttyb-mode line?
05:27:11 <jclulow> ttyb-mode=115200,8,n,1,-
05:28:29 <tsoome> the /boot/defaults/loader.conf attempts to set all 4 ports for console, but if it fails to recognize any serial ports, those wont appear in console variable
05:28:55 <jclulow> (null)-mode=115200,8,n,1,-
05:28:59 <jclulow> what's (null) haha
05:29:20 <tsoome> now we are getting somewhere:)
05:29:43 <tsoome> is it bios or uefi boot?
05:30:16 <jclulow> I expect it to be EFI, and I see efi-version=2.60 in the environment
05:30:25 <tsoome> ok, so its uefi
05:30:48 <tsoome> and head of gate or some older?
05:31:34 <tsoome> what version is listed by installboot -i /boot/loader64.efi 
05:32:28 <jclulow> Yeah these bits are from heads/stlouis-0-g0a2f410dea which includes 5a33fb2d62b34fc173b7c18e177ad488490815ca from master
05:33:07 <jclulow> Extended version string: 1.1-2024.06.02.1 (MD5 hash: 7fbd8aa511b49d34628ed79ac64d55d5)
05:33:27 <tsoome> ok, so it is current head, thanks
05:33:34 <jclulow> You're welcome
05:34:03 <tsoome> ok, and you do not have access to loader prompt at all?
05:35:04 <jclulow> I can probably figure out wscons access soon
05:36:54 <jclulow> What would you like me to type in there if I can get it
05:37:35 <tsoome> the problem is, there  must be something new/unexpected about serial devices and would help if we could get uefi device paths for serial ports - ConIn, ConOut and ConInDev ConOutDev values
05:38:00 <tsoome> so, its efi-show -g global -v ConIn etc
05:40:16 <tsoome> the core of the problem is that with UEFI, the identification of serial ports is just pain:(
05:40:57 <tozhu> I have a additional question, is there any GUI tool that can watch system running status? eg: process running, memory usage, IO statistics, disk space, disk usage and so on, is there any advice?
05:41:55 <tsoome> and to make things worse, some systems crash whn you attempt to use io ports directly, as we do with bios
05:48:16 <tsoome> (null)-mode would of course mean that we did allocate structure for serial port but we failed to create name for it, and that definitely does sound like my bug:(
05:49:12 <tsoome> if anything, then I would have hoped to see name like tty0 there, for unrecognized case
05:49:42 <jclulow> I do _also_ see a tty0
05:50:04 <tsoome> hm. ok...
05:50:06 <jclulow> (null)-mode=115200,8,n,1,- (null)-spcr-mode=115200,8,n,1,- tty0-mode=115200,8,n,1,- tty0-spcr-mode=115200,8,n,1,- ttya-mode=9600,8,n,1,- ttya-spcr-mode=115200,8,n,1,- ttyb-mode=115200,8,n,1,- ttyc-mode=9600,8,n,1,- ttyd-mode=9600,8,n,1,-
05:50:12 <jclulow> that's everything that matches "mode"
05:50:40 <tsoome> i see
05:51:42 <tsoome> ok, I need to walk the dog now, then later I can see into it....  
05:51:53 <tsoome> and sorry for the mess...
05:52:40 <jclulow> all good!
05:52:47 <jclulow> I will figure out how to get at the console
06:28:04 <gitomat> [illumos-gate] 16650 Fix coverity defects: CID 147610, 147608, 147607 -- cao <cao.xuewen⊙zcc>
06:29:00 <tsoome> interesting, git push/pull from gate is appearing at slow side...
06:36:07 <gitomat> [illumos-gate] 16651 zfs: Fix coverity defects: 147658, 147652, 147651 -- cao <cao.xuewen⊙zcc>
06:36:59 <jclulow> tsoome: from code.illumos.org or from github.com/illumos/illumos-gate
06:37:16 <tozhu> and one more question: for zfs_txg_timeout parater, eg: set it to 30s, my rdbms is commited to zfs, and duration the 30s, eg at the 20s, the system lost the power, then the data will lost for my rdbms?
06:37:46 <jclulow> tozhu: as long as your database correctly calls fsync() on files, and checks the return code, you won't lose any data
06:37:58 <richlowe> I would hope your database system called fsync()!
06:38:05 <jclulow> one would hope, but I would not assume!
06:38:17 <jclulow> I would not tune zfs_txg_timeout though
06:40:07 <tozhu> jclulow: Thank you, for a busy system, eg a lot of write, we hope the data can be write in a big batch,   
06:40:34 <tozhu> so we want to tune it to 20s, even 30s
06:41:35 <jclulow> I wouldn't assume that would help
06:41:39 <richlowe> well, that's not really going to happen with a database, because it will fsync() (hopefully), it also has the same issue as garbage-collection, where the longer you wait, the (probably) longer it will take to happen
06:41:45 <jclulow> Right
06:41:58 <jclulow> Is your pool on SSDs or on rotational disks?
06:42:23 <tozhu> on SSD (NVMe)
06:42:33 <tsoome> jclulow upstream        tsoome⊙cio:illumos-gate.git -- this one
06:42:34 <jclulow> Ok, that's a good start.  What's the vdev topology?
06:42:47 <jclulow> tsoome: I just restarted gerrit, the JVM was getting pretty big
06:42:51 <jclulow> let me know if it's still crap
06:43:05 <tozhu> we prefer SSD than HDD/SAS disk for performance
06:43:25 <jclulow> Yes, definitely
06:43:32 <jclulow> what's the vdev topology?
06:43:45 <jclulow> is it a single mirrored pair?
06:43:56 <tozhu> we use mirror, always mirror
06:44:05 <jclulow> that's good
06:44:19 <jclulow> So, really, what I would do is look at the VFS operations your database is actually doing
06:44:22 <tozhu> usually  4 SSD, on 2 mirror vdev 
06:44:39 <jclulow> is it doing a lot of write(), or read(), is it doing a lot of fsync()
06:44:43 <jclulow> are those blocking
06:44:48 <jclulow> if they are blocking, what are they blocking on
06:44:55 <tsoome> jclulow yes, it is much better now
06:45:04 <tsoome> thanks!
06:45:05 <jclulow> tsoome: ok, I'll keep an eye on the bloat
06:45:21 <tozhu> there are a lot of write,
06:45:24 <jclulow> if adjusting zfs_txg_timeout is going to help performance, you would _see_ that somehow in the result of investigating where the DB is hitting bottlenecks
06:46:13 <tozhu> according to the accounting, it’s about 150M/s writes in 8k block size,
06:46:50 <jclulow> do you have a performance target in mind
06:48:04 <tozhu> yes, we hope the latency less 1ms
06:48:24 <jclulow> latency of DB-level operations, or do you mean latency of an individual write() call
06:49:06 <tozhu> we have calcauted, SSD (NVMe) had 4G bw, it can handle
06:49:25 <tozhu> in DB level
06:49:31 <jclulow> ok, that's exciting
06:49:52 <jclulow> do you have a distribution of latencies for how it's performing now?
06:50:35 <jclulow> ideally a histogram obviously but if you have p50, p90, p95, p99, etc, that can help too
06:51:21 <tozhu> we hope get the data from OS level, but I don’t know how to collect the statics from OS
06:51:49 <tozhu> so I ask the question early, if there is any good tool to do that
06:53:28 <jclulow> Collecting OS level data is a good plan, but I would start your investigation at the point where you've got a performance target
06:53:54 <jclulow> i.e., if you want each DB request to be completed within 1msec, you need to be able to look at the life cycle of a DB request as it executes
06:54:25 <jclulow> when it starts, when it is complete; was it hot on CPU the whole time or did it block for something, and if so, what did it block for?
06:54:56 <jclulow> Assuming it's blocking on something, what is _that_ thing blocking on, etc; eventually you'll get to some bottleneck in ZFS or the disks or whatever
06:55:10 <jclulow> or, you won't, and it's just the speed that your software is able to go at on your hardware
06:55:35 <jclulow> (though I've obviously never seen a system that has had no performance work done, and somehow is going as fast as possible, haha)
06:55:35 <tozhu> got it, thank you very much
06:56:22 <jclulow> You're welcome!  I'm sure folks will be able to help you along once you figure out what the DB is up to etc
06:56:46 <tozhu> yes, it’s true
10:07:03 <gitomat> [illumos-gate] 16657 fnmatch(3c) typos FNM_CASEFOLD as FNM_FOLDCASE -- Ahelenia Ziemiańska <nabijaczleweli⊙nx>
20:05:40 <sjorge> I have so many questions after reading message to the developer list.
20:27:37 <richlowe> like what?
20:27:57 <richlowe> I am waiting for builds and could answer questions?
22:05:35 <gitomat> [illumos-gate] 16659 Clean up minor issues in prototype.man3x -- Robert Mustacchi <rm⊙fo>