OSNews

"The longer I use OS X, the more it becomes painfully apparent how badly the kernel sucks...."

_______________________________

It would really be worth an article, if you can find the time, to explain this at reasonable length. Agree or disagree, it will certainly be worth careful reading. Hope you can find the time.

Speaking of OS X and filesystems, Slashdot recently had a thread going about Mac automated backup solutions. pesc brought up this gem: http://blog.plasticsfuture.org/2006/03/05/the-state-of-backup-and-c... While the writeup is generally about backup software, it's goes into a lot of detail about how OS X handles metadata.

Brief synopsis: be glad you aren't in the business of making automatic backup software for Macs!

If you decide to go ahead, drop me an e-mail. I've seriously thought about writing something like that myself.

Being a Linux guy myself, last September I bought a MacBookPro. I was on a hiatus using OSX for nearly two months non-stop. I thoroughly understand what you say about its kernel. The interface is very flashy and all, but seriously, its kernel is far worse than an unoptimized... I don't know what to compare it to.

Once I an on Linux (2.6 + CK) full time again, I feel I have unleashed the real power this machine has.
Tell me about leaving a lengthy CPU bound process like encoding an HDTV video with x264. You get a barely usable system on OSX, even nicing it +19. On Linux, I can keep doing that not only way faster than it was on OSX, but interactivity doesn't suffer at all.

I'd need to compile myself mplayer on OSX, tweaking it the way I do on Gentoo, to do a fair comparison. But still, the difference is awesome.

My 2¢.

I'm afraid an article like that would just invite a flame-fest. But I'd be happy to summarize some of the most glaring problems that I've encountered.

1) The toolchain is just weird. If Apple was going to use the GNU toolchain, they should have done it properly, by adding support for Mach-O to BFD, and fixing the GNU tools so they could target Mach-O, just as they can target PEF for Windows. However, Apple chose to instead ship custom hacked-up versions of the GNU tools. While that is a solution, for people writing software, Darwin's "almost GNU but not really" toolchain is a complication that could've been avoided. In an ideal world, they would've used ELF like everyone else and avoided the problem entirely, but that's probably too much to ask.

2) Darwin's shared library infrastructure is... strange. Mach-O just isn't as clean a format as ELF. There are fairly arbitrary distinctions between loadable modules and shared libraries, restrictions on section types in dynamic libraries, etc. The linker is also slow, and startup of programs with extensive shared library dependencies is pokey.

3) The Mach/BSD API schism is not entertaining, to say the least. Their tracking of the FreeBSD API has stagnated since 5.x. Darwin is BSD... almost.

4) The system does not handle huge VM loads gracefully. Giant compiles won't even cause Linux to blink, while they'll cause Darwin to have very noticable hiccups.

5) I/O performance, and general system performance under high I/O loads is not steller.

6) Many primitive UNIX operations (process/thread creation, page-fault handling, etc) are much slower on Darwin than on Linux. This has been documented repeatedly, and extensively.

In the grand scheme of things, Darwin just isn't very good, at anything, except maybe low-latency audio. It just doesn't deliver what I'd expect from a modern, high-performance UNIX kernel. It's not as scalable as Solaris, its not as fast as Linux, its not as stable as FreeBSD, its not as clean and elegant as NetBSD, etc, etc, etc. It's merely "good enough", what Apple inherited when it bought NeXT, and what they surely realize is behind all of the major competition, but what they (rightly) think is not enough of a handicap in their target market to be worth the trouble of replacing.

Innovation's nice, but last I checked Reiser4's performance was somewhat lacking.

It's also been seriously neutered since the original design... all of the innovative metadata features have been removed (or never implemented). The implementation (a hidden directory filled with files containing the metadata) was a bit wacky, but it was a great idea exposing a file's metadata "directory" so it could be manipulated by standard tools.

- chrish

he longer I use OS X, the more it becomes painfully apparent how badly the kernel sucks, and any step forward is a much needed one.

Yeah, you are telling us that you are able to talk directly with the kernel.

How many people can feel how bad is a kernel while using an application ...

Well, I might say that if you've been customizing a kernel for some time, seeing the progress along yourself, noticing the impact different changes have had, without even having to program it directly, you'd definitely be able to realize it's the kernel what really sucks on OSX.

Try to put the machine to its limits, and it'll become readily apparent how many of the progresses Linux has made over the years (specially since 2.6) are not still there on OSX.

I swear I can't understand how OSX on servers is doing anything out there.
Could someone with experience on it comment whether there are important changes between the desktop and server version of OSX, WRT its kernel?

Well regarding your comments on ZFS, I will just quote a Sun engineer.

ReiserFS v4 may be a significant step forward for Linux file systems, but looking through the feature list on its Web site, I don't see anything like the ability to add storage space dynamically or integrated checksums to protect against data corruption. ReiserFS v4 is also not 128-bit, so its ceiling is much lower than that of ZFS.

http://blogs.sun.com/dilpreet/entry/nice_s10_article

I'm not a big Reiser4 fan. While it is certainly interesting, one must be careful to sort the hype from the reality. And Namesys is very good at hype. I lost some faith in it when it was exposed that benchmarks on the Namesys site had the phases of the benchmark where ext3 beats Reiser4 (and badly) systematically removed, a situation that still has not been corrected years after Hans admitted to it on lkml. (I can dig up a link if requested.)

Plus, looking over the threads on lkml, I get the impression that the most interesting stuff, like file as directory, is not necessarily safe.

Furthermore, the most interesting features are not ones that developers could really use. For example, its database-like speed with large numbers of objects, and the file as directory semantics might make it easier to to write certain kinds of programs, even eliminating the need for a database... as long as you are writing for Linux only and don't care about portability. If you do care about portability, you have to write it to run on other filesystems anyway, and that same code would work on Linux. So why bother writing it 2 ways?

ZFS has features that would be useful right now, and without the drawbacks, which is why I give it the nod over Reiser4.

Reiser4 is pretty well-hyped, but the underlying concepts really are sound, and are very innovative. The major benefits in Reiser4 are the following:

1) Seperation of the storage layer and the semantic layer. Hierarchical filesystems need to go, for the simple reason that years of experience has shown that most people really don't understand them. All the unexperienced computers I know have "My Documents" directories with hundreds of files in it, because it doesn't occur to them to create subdirectories, and the only reason its even in "My Documents" to begin with is that Word defaults to there. Seperating the storage layer from the semantic layer is a prerequisite to moving the semantic layer towards something people find usable.

2) High-performance storage of small files. Storing data in small files is a good thing. BeOS did it, and OS X is doing it (Spotlight's architecture is really set up for it). Search-based filesystems, in one way or the other, are going to be a UI paradigm that'll weigh heavily in the future, and Reiser4's design is better positioned to take advantage of it than any other filesystem.

The politics surrounding Reiser4 are regretable, and from a quality of implementation point of view, I have no doubt ZFS is much more solid and trusthworthy. But ZFS's design is a baby-step while Reiser4's is a giant leap, and I think that deserves an enormous amount of credit.

1) Seperation of the storage layer and the semantic layer. Hierarchical filesystems need to go, for the simple reason that years of experience has shown that most people really don't understand them. All the unexperienced computers I know have "My Documents" directories with hundreds of files in it, because it doesn't occur to them to create subdirectories, and the only reason its even in "My Documents" to begin with is that Word defaults to there. Seperating the storage layer from the semantic layer is a prerequisite to moving the semantic layer towards something people find usable.

ZFS has that separation. The Posix semantics are handled by the ZPL (ZFS posix layer), which interacts with the DMU ( Data Management unit) for storage operations on object. Like the UNIX directory plugin works in Reiser4.

From the OpenSolaris website.
"The DMU is responsible for presenting a transactional object model, built atop the flat address space presented by the SPA. Consumers interact with the DMU via objsets, objects, and transactions. An objset is a collection of objects, where each object is an arbitrary piece of storage from the SPA. Each transaction is a series of operations that must be committed to disk as a group; it is central to the on-disk consistency for ZFS."

Clients of the DMU furthermore include the ZVOL volume interface and /dev/zfs. ZFS already has a clear separation of the storage layer and semantic interface layer.

http://www.opensolaris.org/os/community/zfs/source/
You might find this useful to read.

If Applications require the kind of separation, it wouldn't be hard to create another interface on top of the DMU to accommodate them.

I would say that ZFS is second to Reiser4. Reiser4 is a far more innovative filesystem that really addresses the point that byte-streams are just byte-streams, and that any distinction between metadata and data is just arbitrary.

I disagree. If meta-data and data distinction is the only feature that marks innovation in filesystems then maybe Reiser4 is more innovative.

ZFS completely redefines storage on a computer by making it more like main memory. What do you do on a box if you need more memory? Add a DIMM and presto more memory instantly no extra work required. With ZFS you need more storage space for your filesystems just add a disk or too and presto instantly more space, no extra work required.

Snapshots, clones and block checksums make it far more innovative than any other filesystem I am aware of. More users can use those features right away than one innovative feature in Reiser4 that only developers can use that too if it becomes popular enough.

The snapshot and cloning features for ZFS makes it perfect for Timemachine in leopard. Snapshots and clones don't take up extra space because of ZFS' COW semantics and are pretty instantaneous. ZFS can create volumes on which you can overlay other filesystem types. Apple could make a ZFS volume and overlay HFS+ on it and have all the ZFS features like cloning and snapshots and maintain backward compatibility.