ok

is there currently a recommended way of setting zfs ashift parameter for SSDs or is it done automagically?

for advanced format HDDs I've set ashift=12 just to make sure

looking at a few SSD I probably didn't set it, "zpool get ashift mypool" shows that ashift=0 and zdb shows =9

holin: It depends on what the SSD firmware tells us about the block size of the device

Some SSDs correctly say they support a physical block size (e.g., 4K) that is distinct from the logical block size (e.g., 512B)

And some just say the logical size

does illumos have any tools to get that? smartctl shows 512/512 for all (SATA) SSDs that I have

You know, I actually don't remember how to fish it out

Ultimately if you absolutely want a 4k (=12) pool, you should probably specify it

But we will under many conditions do the right thing

Frankly, I've never cared about this on SSDs, thinking that trying to too clever on the user's side will likely just go against the SSD firmware trying to also be clever, but now I got some new disks and thought about trying to be clever nonetheless :-)

If they are NVMe disks, you may be able to reconfigure/"reformat" them to be 4k native

Which might allow them to perform better, depending on how smart the firmware is

See the "format" subcommand in nvmeadm(8)

haha.. i managed to make reboot(1M) segfault somehow

actually.. ficlVmInnerLoop is crashing (called by be_get_boot_args)

one other thing regarding SSDs: does setting autotrim make sense? On linux I have usually a cron job doing manual TRIM once a week..

I think trim has generally been found to improve performance on consumer grade SSDs, even on some enterprise SSDs that supposedly don't need it

It's pretty deep firmware magic though, so it could also make things worse

If you care about the performance you'll probably need to do experiments with your particular workload

and your particular drives and firmware revisions

it also wouldn't be surprising if it also depended on how full your SSD is

for the drives at hand, longevity is more important than performance. These are consumer grade SSDs fwiw.

btw. does illumos have the NCQ TRIM exceptions for Samsung EVO 850/860 drives that Linux has?

have some of those around, too, and might end up using them for illumos deployments

jbk core?

what could possibly make a disk not seen by illumos? Two SSDs behind mpt2sas controller and linux sees them both, while illumos (oi) only sees one according to "format" and also /dev/rdsk

identical, unformatted (unpartitioned) SSDs

previously the same bays/slots had two other disks which showed up fine

i'm thinking that not having partition table has something to do with this..

holin - do they show up in the output of `diskinfo`?

no, same thing as format

i could try partitioning in linux and see how that goes

diskinfo shouldn't care about the partition table - any difference if you run it a second time?

Another command that shows disks is `iostat -En`

iostat shows the same thing also

one'd think that if it was the disks (incompatible etc.), neither would show up; if it was the controller, the previous two disks wouldn't have worked either

That's strange. It definitely sounds like it's worth doing what you suggested

d'oh. gave them gpt disklabels with parted and still no dice

my second guess: the disks differ only by the last three digits in their serial# so maybe whatever in illumos generated the disk id's uses too few digits and gets confused(?)

(i.e. considers the disks the same)

the previous, also identical, disks had a bigger difference in serial#

the ports on the motherboard get names like c3t1d0 c3t2d0 c3t3d0 and so forth

these disk behind the mpt2sas controller all start with c4t3 juxtaposed with something generated from the disk identification info

so, it would at least appear possible to have collisions in device ids

Here's an interesting discovery: With MTU=9000 on all of: a vnic on an aggr over two mlxcx physical interfaces, something above mac_ring_tx is dividing outbound messages into 1460 byte segments. That means mlxcx always copies here: src.illumos.org/source/xref/illumos…/mlxcx/mlxcx_ring.c?r=7fdea60d#2268

[illumos-gate] 15016 find_elf should cope with O_DIRECTORY absence -- Yuri Pankov <ypankov⊙tc>

gwr: a question for dan, or dtrace, or both?

gwr: Is it a local LAN, or is it possible there has been some path MTU detection keeping it down