This is close on the heels of DragonflyBSD doing the same thing. I can't say I blame them as packaging software is a painful experience with, as far as I can tell, limited reward. :)
Welcome!
Today at work I found out some details about ext4 and how its journal settings can really affect different workloads.
The default data=ordered and data=writeback give good performance for operations on larger files.
dd if=/dev/zero bs=1024 count=1000000 of=/var/dout2 and variants were 2-3x faster than ext3
perl -e '$|++; for($x = 0; $x < 10000; $x++) { open(FH, "+>", "/var/file") or die "$!"; print FH "hello, world\n"; close FH; }' was 50x SLOWER, however.
Another interesting point on this is to run tail -F /var/file during the test on ext4 vs ext3. It will become pretty obvious where the problem is- ext3 only writes the contents of the file once whereas ext4 does what you thought you asked it to do.
Switching to data=journal basically turned ext4 into ext3 in terms of performance, making my 1GB dd's slower and my perl script faster
pid 27586 (varnishd), uid 32767: exited on signal 11 (core not dumped, err = 1)
After some time I figured out that it wasn't a varnish setting or anything like that, it was more likely a problem with netbsd not allowing the core file to be written!
sysctl(8) has an example.
sysctl(7) has a definition.
default sysctl.conf has another tip.
Anyway, change the following in /etc/sysctl.conf:
kern.defcorename=/var/tmp/%n.core
sysctl -w kern.defcorename=/var/tmp/%n.coreNow core files should end up in /var/tmp, which has sticky bit and should allow for anyone to write.
and old mention of wasabi which may no longer be true..
Even though netbsd has had iSCSI for a while, this might improve performance and has been out in the real market on enterprise installations for years, so it's definitely proven.