2014-02-07
A surprise with OmniOS disk sizing: the rpool/dump ZVOL
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.)