I guess it is here, too

I guess I have exactly the setup you do, except for a v. b

and it working

:\

(none of it at all reflected in eeprom(8))

but /system/boot/environment agrees with it

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 ?

I read some docs, it is required on Linux, I’m not sure if it’s required too on illumos/smartos

best wishes for the answer

tozhu: If your disks advertise themselves as having 4k blocks, we'll create a 4k block sized pool by default; i.e., ashift=12

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?

If your disks advertise themselves as having 4k blocks, then yes, it will be created with 4k blocks automatically

If not, then you would have to override

okay, got it, Thank you very much for the answer

You are most welcome!

jclulow does ttyb exists?

yes, if I 'date >/dev/term/b' it pops out on the console. Indeed, on much older illumos bits, the console worked correctly!

on loader prompt, is console=ttyb ?

I don't see the loader prompt

I mean, if you end up with console=text, it means that either the value is overwritten in loader or dboot/locore

right

unless it fails to set it to ttyb in first place...

jclulow@astrid ~ $ tr '\0' '\n' < /system/boot/environment | grep ^console

console=text,ttya

I guess it's probably setting it to that!

Despite what I told it to use haha

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

does environment list ttyb-mode line?

ttyb-mode=115200,8,n,1,-

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

(null)-mode=115200,8,n,1,-

what's (null) haha

now we are getting somewhere:)

is it bios or uefi boot?

I expect it to be EFI, and I see efi-version=2.60 in the environment

ok, so its uefi

and head of gate or some older?

what version is listed by installboot -i /boot/loader64.efi

Yeah these bits are from heads/stlouis-0-g0a2f410dea which includes 5a33fb2d62b34fc173b7c18e177ad488490815ca from master

Extended version string: 1.1-2024.06.02.1 (MD5 hash: 7fbd8aa511b49d34628ed79ac64d55d5)

ok, so it is current head, thanks

You're welcome

ok, and you do not have access to loader prompt at all?

I can probably figure out wscons access soon

What would you like me to type in there if I can get it

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

so, its efi-show -g global -v ConIn etc

the core of the problem is that with UEFI, the identification of serial ports is just pain:(

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?

and to make things worse, some systems crash whn you attempt to use io ports directly, as we do with bios

(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:(

if anything, then I would have hoped to see name like tty0 there, for unrecognized case

I do _also_ see a tty0

hm. ok...

(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,-

that's everything that matches "mode"

i see

ok, I need to walk the dog now, then later I can see into it....

and sorry for the mess...

all good!

I will figure out how to get at the console

[illumos-gate] 16650 Fix coverity defects: CID 147610, 147608, 147607 -- cao <cao.xuewen⊙zcc>

interesting, git push/pull from gate is appearing at slow side...

[illumos-gate] 16651 zfs: Fix coverity defects: 147658, 147652, 147651 -- cao <cao.xuewen⊙zcc>

tsoome: from code.illumos.org or from github.com/illumos/illumos-gate

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?

tozhu: as long as your database correctly calls fsync() on files, and checks the return code, you won't lose any data

I would hope your database system called fsync()!

one would hope, but I would not assume!

I would not tune zfs_txg_timeout though

jclulow: Thank you, for a busy system, eg a lot of write, we hope the data can be write in a big batch,

so we want to tune it to 20s, even 30s

I wouldn't assume that would help

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

Right

Is your pool on SSDs or on rotational disks?

on SSD (NVMe)

jclulow upstream tsoome⊙cio:illumos-gate.git -- this one

Ok, that's a good start. What's the vdev topology?

tsoome: I just restarted gerrit, the JVM was getting pretty big

let me know if it's still crap

we prefer SSD than HDD/SAS disk for performance

Yes, definitely

what's the vdev topology?

is it a single mirrored pair?

we use mirror, always mirror

that's good

So, really, what I would do is look at the VFS operations your database is actually doing

usually 4 SSD, on 2 mirror vdev

is it doing a lot of write(), or read(), is it doing a lot of fsync()

are those blocking

if they are blocking, what are they blocking on

jclulow yes, it is much better now

thanks!

tsoome: ok, I'll keep an eye on the bloat

there are a lot of write,

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

according to the accounting, it’s about 150M/s writes in 8k block size,

do you have a performance target in mind

yes, we hope the latency less 1ms

latency of DB-level operations, or do you mean latency of an individual write() call

we have calcauted, SSD (NVMe) had 4G bw, it can handle

in DB level

ok, that's exciting

do you have a distribution of latencies for how it's performing now?

ideally a histogram obviously but if you have p50, p90, p95, p99, etc, that can help too

we hope get the data from OS level, but I don’t know how to collect the statics from OS

so I ask the question early, if there is any good tool to do that

Collecting OS level data is a good plan, but I would start your investigation at the point where you've got a performance target

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

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?

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

or, you won't, and it's just the speed that your software is able to go at on your hardware

(though I've obviously never seen a system that has had no performance work done, and somehow is going as fast as possible, haha)

got it, thank you very much

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

yes, it’s true

[illumos-gate] 16657 fnmatch(3c) typos FNM_CASEFOLD as FNM_FOLDCASE -- Ahelenia Ziemiańska <nabijaczleweli⊙nx>

I have so many questions after reading message to the developer list.

like what?

I am waiting for builds and could answer questions?

[illumos-gate] 16659 Clean up minor issues in prototype.man3x -- Robert Mustacchi <rm⊙fo>