Date: Mon, 30 Nov 2009 21:51:26 +0000 From: Bruce Cran <bruce@cran.org.uk> To: James Phillips <anti_spam256@yahoo.ca> Cc: freebsd-questions@freebsd.org Subject: Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0? Message-ID: <20091130215126.0000563c@unknown> In-Reply-To: <774934.16234.qm@web65513.mail.ac4.yahoo.com> References: <20091130120015.4F7AD10656CA@hub.freebsd.org> <774934.16234.qm@web65513.mail.ac4.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Nov 2009 09:22:17 -0800 (PST) James Phillips <anti_spam256@yahoo.ca> wrote: > > > Date: Mon, 30 Nov 2009 20:07:15 +1100 > > From: alex <alex@mailinglist.ahhyes.net> > > Subject: Re: Phoronix Benchmarks: Waht's wrong with FreeBSD > > 8.0? > > To: freebsd-questions@freebsd.org > > Message-ID: <4B138B43.4000809@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091130215126.0000563c>