Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?

[Bruce Cran]

On Mon, 30 Nov 2009 09:22:17 -0800 (PST)
James Phillips <anti_spam256 at yahoo.ca> wrote:

> 
> > Date: Mon, 30 Nov 2009 20:07:15 +1100
> > From: alex <alex at mailinglist.ahhyes.net>
> > Subject: Re: Phoronix Benchmarks: Waht's wrong with FreeBSD
> > 8.0?
> > To: freebsd-questions at freebsd.org
> > Message-ID: <4B138B43.4000809 at mailinglist.ahhyes.net>
> > 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:
> > 
> > http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1
> >
> > 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
> http://www.h-online.com/open/news/item/Ext4-data-loss-explanations-and-workarounds-740671.html
> 
> Ext4 data loss Bug #317781 (Fix released)
> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781
> 
> "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

This is actually the way UFS/FFS works too: when my system was crashing
fairly regularly I was a bit surprised to find empty files after
editing them.

Also, I just verified that saving a file, rebooting, editing it again
(with ee(1)) and powering off the system does still result in a zero
length file being on disk.


-- 
Bruce Cran