Disk performance is also lacking in comparison to the ubuntu droplet as shown in the pastebin. Could just be because everyone's spinning up fbsd boxes on this host? :)
If you wish to have higher disk speeds, but not use backups, we recommend for you to remount your disk with journaling.
What else has DO disabled and/or modified from a vanilla install?
DO have screwed something up with their configuration if they need to make so many changes to make it work. No other VPS provider I have used that support FreeBSD (or OpenBSD for that matter) require any changes to the default install.
Shouldn't this make it much faster as the FS no longer maintains a journal?
The parent link to gjournal is weird too, since gjournal is not the same as softupdates w/journaling (SU+J). It makes me wonder if they actually disabled softupdates too.
I found a random post about issues (unmapped io?) running i386 freebsd with su+j in virtualbox (apparently a virtualbox bug).
Second console actually disables access from web console access, which is fatal.
Autoboot is not critical, although default to 3 sec should work much better for opportunity to change boot options from web console.
After performing some tests I figure out that the problem was not FreeBSD per se, but the FreeBSD deployment on the specific virtual server... I think that *BSDs should be avoided because they tend to be a lot slower than linux deployments on virtual machines.
Many virtualisation providers don't support it properly, but "should be avoided because my suppliers are stupid" is a terrible plan.
16384+0 records in
16384+0 records out
1073741824 bytes transferred in 57.605991 secs (18639412 bytes/sec)
0.023u 6.128s 0:57.61 10.6% 25+172k 7+81916io 3pf+0w
> sudo mount -o nosync -u /
/dev/gpt/rootfs on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
> time dd if=/dev/zero of=/tmp/test bs=64k count=16k
1073741824 bytes transferred in 5.135908 secs (209065631 bytes/sec)
0.016u 2.274s 0:05.16 44.1% 24+169k 8+8193io 0pf+0w