The clocks have fallen back, the leaves are hitting the ground and new BSD releases are on the Net. Among all the noise and buzz created by Linux, it's important to remember that it's not the only open source variant of Unix. OpenBSD, NetBSD and FreeBSD are all still very much alive and kicking and have recently been released from their respective projects.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-06-29
Yes, and I can tell you why... It's not as strict. When I used to code on fbsd I was always amazed at how I almost never seemed to have memory troubles. Then I tried the code on a Linux machine and found it crashing consistently at several spots which worked perfectly on fbsd.
This doesn't matter so much for users, but for developing: It really stinks. In fact, it's probably nice for users... Well, until the program corrupts its data so bad it can't save their work...
But, I can't imagine releasing something *that* messed up.
Member since: Journaling is, after all, a hack.
Actually, it's not. Softupdates is indeed very elegant, but it merely helps guarantee that there will be fewer/no inconsistencies that result in damage. It doesn't remove the need for a complete scan and validation of the metadata after an unexpected shutdown. This need for a 'fsck' is a liability since it means that system is still unusable for a time once you try to bring it back up. Imagine if you unplugged your TiVo and then had to wait 30 minutes to use it after you plugged it back in. Background fsck does try to hide this by allowing the system to run normally while a fsck goes on in the background, but it's never been as reliable as it should be and is thus not a good option for embedded or enterprise use.
Journalling, when done right, is very effective. No need for a fsck, just a quick linear replay of a relatively small bit of data. The potential performance loss from doubling writes through the journal is made up by making the accesses more linear and predictable for the drive. And while you might think it's a hack to encapsulate metadata changes into atomic operations, it's been incorporated into just about every filesystem written since the early-1990s.
UFS and Softupdates do perform well, but the need for journalling is inevitable.
Member since:
Member since:Actually, you don't need to run fsck at all after a reboot, with softupdates. All background fsck does is reclaim unused space.
Also the advantage of doubling writes in journalling is not making accesses more linear and predictable. The real advantage is that it only requires you to only write the metadata synchronously, letting you safely delay the writing of the (non-metadata) data for longer, thus saving you several disk writes for data that is written often.
Softupdates also has this advantage (and in fact, needs even less synchronous writes than journalling, in most cases).
The real problem with softupdates is the code complexity, which is much higher than journaling.
Also, ATA disks often lie when they say something has been committed to disk, because of their write cache, which might introduce some unexpected inconsistencies in the filesystem if a crash happens at the wrong time. However, this also affects journaling.
Member since:
Member since:Right, journalling is a hack, that's why there's ongoing effort to add it to UFS2/3, and even the GEOM layer (http://www.freebsd.org/projects/summerofcode.html)
Member since:
And it doesn't need a journaling FS. Its alternative (soft updates & snapshots) provides a more sensiable alternative. Google for the relavent papers, there interesting and a worth while read. Journaling is, after all, a hack.
And it is perhaps worth noting that for a long time FreeBSD had far superior memory management to linux. When I switched from Linux to FreeBSD my loki games all ran noticablly faster on the same hardware. It got fine grained SMP support about the same time linux got proper memory managment.