Until recently, all of my work installing and reinstalling OmniOS has been in a virtual machine, which had a modest configuration. Recently I started doing test installs on our real fileserver hardware, which resulted in a disk sizing surprise in the default OmniOS install.

Our fileserver hardware has 64 GB of RAM and an 80 GB SSD system disk (well, two of them but they're mirrored). On this hardware the OmniOS installer set up a dedicated 32 GB chunk of space for kernel dumps (the rpool/dump ZFS volume). On the one hand, this is very much not what I wanted; I definitely don't want half of a quite limited amount of disk space to disappear to something which I expect to never use. On the other hand you can argue that this is at least half rational as an OmniOS default, since OmniOS itself needs almost no disk space. If you probably need 32 GB of kernel dump space for safety and the disk space is there, you might as well use it for something.

(I call this only half rational because I'm not sure there's enough space left in /var to write out a kernel dump that actually needs all of that 32 GB of dump ZVOL, since both OmniOS itself and the swap ZVOL use of some of the remaining space.)

The normal installer image doesn't give you a convenient way to customize this, so my workaround is to simply delete the dump ZVOL after installation:

dumpadm -d none
zfs destroy rpool/dump

If our OmniOS systems ever start crashing in a situation where a crash dump might be useful, we can revisit this and perhaps recreate a rpool/dump ZVOL of some suitable size.

(The OmniOS installer also defaulted to a 4 GB swap ZVOL. On the one hand this strikes me as excessive; on the other hand it's only 4 GB and swapping to and from a SSD is going to be a bunch faster than a traditional hard disk swap so having to go to swap might be quite as terrible as it used to be. We're leaving the swap ZVOL alone for now.)