FreeBSD Status Report for 2005 Q2

koinu writes "FreeBSD Status Report for the second quarter 2005 has been published by Scott Long. It gives a more precise description of what is being done on the 18 Summer Of Code projects." From the post: "The Google Summer of Code project has also generated quite a bit of excitement. FreeBSD has been granted 18 funded mentorship spots, the fourth most of all of participating organizations. Projects being worked on range from UFS Journalling to porting the new BSDInstaller to redesigning the venerable www.FreeBSD.org website."

Comments

that's close to the truth

[r00t]

There are many types of journalling. The ext3 filesystem alone supports three! You can journal all data (extreme), you can journal metadata prior to writing plain data, or you can just journal the metadata.

There is softupdates, which orders things a bit. After a crash, there should be (knock on wood) only a few minor errors related to free space not being marked free.

There is sync, the traditional and fairly slow way. This generally provides unneeded determinism for directory operations. Normally we want as many pre-crash changes as possible, not just ones that can be made in perfect order. Some very unportable BSD software relys on sync behavior.

There is async, which plays fast and loose with everything. This works rather poorly on FreeBSD. It is likely that fsck will make a mess on boot, and illogically an async mount is slower than a softupdates mount. Linux has a nearly-true async, the default for ext2, that is very fast. (if an app explicitly requests a sync, the request is not ignored) The ext2 fsck is also extremely reliable, allowing for recovery of async filesystems that would be unheard of in the BSD world.

So that is:

• async
• sync
• soft updates
• full data journalling
• ordered data journalling
• metadata journalling

(and the patented obsolete delayed ordered writes from SysV, if I remember right)

The really strange thing is that sometimes heavy-duty journalling can be fastest. This is often the case with mail servers which explicitly sync data to disk. A full-data journalling filesystem (as ext3 can be) may legitimately report completion as soon as the data hits the log, which is a nice big linear disk write. Other filesystems, though faster for normal use, will have to seek all over the disk before they can legitimately report completion.

Modern hardware screws all of this up horribly though. As the XFS developers discovered to their horror, power loss will corrupt data in memory or in transit to the disk before it stops the disk from operating. (yes, even when using appropriate fence or flush operations) Uh oh...

Re:Tired of obligatory *BSD is dying comments

[Anonymous Coward]

Sir, this post is to warn you that we Anonymous Cowards do not value your opinion regarding the status of "BSD is dying" posts. Frankly, since Netcraft confirms that BSD is dying, it is clear that BSD is dying. This makes "BSD is dying" posts on topic in the context of an official FreeBSD status report. Now, sir, I suggest you do your part to help the BSD family of operating systems die gracefully by

1. Grounding yourself in the fact that BSD is dying.
2. Stop complaining about the fact that BSD is dying.
3. Removing NetBSD and OpenBSD from your servers/firewall.
4. Installing any VMS derivative operating system you'd like on your servers/firewall.

We Anonymous Cowards understand your frustration. The BSD family was a wonderful group of operating systems, but the time has come for them to finally rest. You have our sympathy.