Okay 40MB cache is an exaggeration, but thats besides the point. UFS (which is really FFS) relies on ordered meta data writes for consistency. This was very much the right way to do things ... uhh ... 20 years ago. Modern harddrives have write caches, the write cache usually reorders writes for efficiency. Well, for FFS, this is
dangerous, especially under heavy I/O. Upon a reboot from a crash, the system will invoke fsck to check the FS. The fsck utility makes assumptions that are no longer necessarily true. Remember, FFS and softupdates rely on ordered meta data writes for consistency, but with write caching on, the writes could have happened in any order. Another problem with FFS is that since it has no journal, the OS can't simply just "unwind" transactions to fix the FS, it has to run fsck ... this can take quite a
long while on large harddrives.
As further proof for the matter, the FreeBSD handbook
briefly mentions this:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html11.12.1.5 hw.ata.wc
FreeBSD 4.3 flirted with turning off IDE write caching. This reduced write bandwidth to IDE disks but was considered necessary due to serious data consistency issues introduced by hard drive vendors. The problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives not only write data to disk out of order, but will sometimes delay writing some blocks indefinitely when under heavy disk loads. A crash or power failure may cause serious file system corruption. FreeBSD's default was changed to be safe. Unfortunately, the result was such a huge performance loss that we changed write caching back to on by default after the release. You should check the default on your system by observing the hw.ata.wc sysctl variable. If IDE write caching is turned off, you can turn it back on by setting the kernel variable back to 1. This must be done from the boot loader at boot time. Attempting to do it after the kernel boots will have no effect.
For more information, please see ata(4).
Please note that, while all harddrives behave this way. The BSD developers still blame the harddrive industry instead of fixing the problem. Thats another problem with the BSD community ... their attitude. I've seen messages and emails on mailing lists where users are arguing with developers on whether a problem is a "bug." I've seen developers call complaining users trolls for making comparisons to Linux about very real problems. BSD also has a bad attitude towards corporation, probably because of the legal battle with AT&T in the 80s and USL/Novell in the 90s. This is partly why they are not popular with business.
NetBSD has a Google Summer of Code project to add journaling to FFS. Although, like ext2, I think the file system ought to be designed from ground up for journaling. I also think that the FreeBSD foundation should purchase ReiserFS with BSDL and integrate it into the system ... or perhaps implement OpenSolaris's ZFS.
http://netbsd-soc.sourceforge.net/projects/jffs/Please note, these are the sour points of BSD. There are plenty of good things about BSD systems so don't dismiss BSD based on the above.
