Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?

James Phillips anti_spam256 at
Mon Nov 30 17:22:19 UTC 2009

> Date: Mon, 30 Nov 2009 20:07:15 +1100
> From: alex <alex at>
> Subject: Re: Phoronix Benchmarks: Waht's wrong with FreeBSD
> 8.0?
> To: freebsd-questions at
> Message-ID: <4B138B43.4000809 at>
> Content-Type: text/plain; charset=ISO-8859-15;
> format=flowed
> I didn't know these were released already, but I had a
> look. I was 
> disappointed with the results.
> If anyone wants to look here is the link:
> Linux's ext4 seems to leave UFS and ZFS well behind in a
> number of 
> benchmarks.

My first thought is that Ext4 may be "cheating" on the benchmarks. The performance regressions should probably be concerning though.

Ext4 data loss; explanations and workarounds

Ext4 data loss Bug #317781 (Fix released)

"If you really want to make sure the data in on disk, you have to use fsync() or fdatasync(). Even with ext3, if you crash at the wrong time, you will also lose data. So it's not the case with ext4 that "it's going to truncate files <i>every time</i> a non-redundant component dies". It's not <b>every time</b>. If you fdatasync() or fsync() the file, once the system call returns you know it will be safely on disk. With the patches, the blocks will be forcibly allocated in the case where you are replacing an existing file, so if you crash, you'll either get the old version (if the commit didn't make it) or the new version (if the commit did make it). If you really care, you could write a program which runs sync() every 5 seconds, or even every 1 second. Your performance will be completely trashed, but that's the way things break." - Theodore Ts'o  wrote on 2009-03-06

Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now

More information about the freebsd-questions mailing list