c0t0d0s0.org

Sometimes i have the strong impression that Linux is the landfill for old filesystems. Linux is now the proud home of AdvFS. as HP contributed the old Tru64 Unix file system to Linux. But: Does Linux really need yet another filesystem? Beside all the other ones ?

A really interesting article written by Jason Perlow at ZDNet: Unixfication II. It´s an insightful article about the different ways to define scalability in the Linux and Unix community and about the effects an GPLv3 Solaris may have.

So these implementations have been tested, but they are not exactly what you would call mainstream systems. And if I’m not correct, you don’t currently see the level of geometric performance increases on Linux above 16 cores like you do with UNIX. The maturity in the Linux kernel for this level of enterprise performance and stability on this type of hardware just isn’t there yet.

The problem for Linux is, that systems with more than 16 cores are available soon (think about an Sun Fire 4600 with Quadcores) and will be quite common when AMD delivers a 12 core version of their processors.

Think about other multicore procs. The announcement of UltraSPARC T2 sound on the hardware side relatively small. Dual Socket or Quad socket isn´t such a big numerical jump. For Solaris this developement means: Jumping from 64 to 128 respectively 256 strands to schedule. And we won´t stop there.

The chance for Linux: Systems with more than 8 cores were out of reach for many developers, and systems with more than 32 cores even for many software developers. Now such machines are relatively cheap and within reach of a community backed by companies, and this may fuel the community effort to optimize Linux for larger SMP systems.

Ubuntu was certified by Canonical on some new hardware from Sun. Now you can buy support for Ubuntu from Canonical for the Sun Fire T5220 and 5240 ( both UltraSPARC T2) and the Sun Ultra 24 (Xeon).

Informationweek did an email interview with Linus Torvalds about the future of Linux: Torvalds On Where Linux Is Headed In 2008. This interview leaved me somewhat dissatisfied ... i would like some information where the development of Linux will lead the operating environment in the next 12 or 24 month. Asked in this direction, the answer was somewhat limited to hardware support:

So a lot of the effort ends up being hardware-related. Both in terms of peripheral drivers and simply in platform changes. The bulk of the kernel really is about hardware support, and that alone keeps us busy. The situation in graphics and wireless networking devices -- both of which have been somewhat weak spots -- is changing, and I suspect that will be a large part of what continues to happen during 2008 too.

I hoped to see something like a ZFS competitor, albeit his thoughts about SSD could hint to something similar like read- and writezilla. More or less, the essence of this interview is: More of the same.

I wrote several times in this blog, that the innovations of Linux aren't technical ones. Linux is a social phenomenon, not a technical one. Now, Paul Murphy wrote a similar opinion in his blog at zdnet: Is Linux innovative?. From my view, Linux on x86 is the triumph of good-enough. It's good enough to be a webserver, it's good enough to be a mailserver, it's good enough for being a datacenter server. It's not really good at it, but it's capable to run 80% of all unixoid tasks sufficiently when you ignore some problems (like RAS being an afterthought in x86 or the inherent problems of storing data on rotating rust)

The marketing problem: Linux get a good market share in areas with the general suspicion of "beeing innovative" like HPC. Fanboys and media digest this image without further thinking and tout it into the world. The problem: The reality isn't so simple. In HPC Linux is little more than a glorified bootloader and device driver for small nodes (the ability to scale on such cluster has nothing to do with the Linux kernel, it's the merit of the application programming frameworks and fast network (like IB) )

PS: This paragraph made my day ....

Similarly people will argue that Linux scales better than anything else. They’ll point, for example, at SGI’s Linux super computers - but those aren’t SMP machines, they’re multi-processor grids in boxes; and, by that logic the world CPU scaling crown would have to go to Microsoft: for botnet, a wanabe grid entirely enabled by Microsoft Windows.

Whenever you speak about Solaris with some Linux fans, they will tell you "I would like to use ZFS, dtrace is so cool ... but well ... i can´t do it ... it´s not in linux. And it´s your fault, because of your OSS license". Okay ... that were multiple persons merged to one citation. But it´s a good summary of all the stuff i hear all the day.

I found two blog entries, that speak out what i think: When you want Solaris feature, just use Solaris, and don´t wait for some shoehorned concept in your favorite religion-laden operating environment. When you think rational about the problem, you should not tied to your operating systems, you should look at your tasks and your applications. And when Solaris fits better than Linux into the equation , just use it ...

But it´s the same with the everlasting dispute about Windows/Unix, vi/emacs: People have a bias regarding their choices. And this bias seldoms comes from rational thinking.

It is just me, or is this statement full of arrogance:

"They've fragmented the non-Windows operating system world and they continue to do so," he said. But he acknowledged he did not see much chance of Sun moving away from Solaris.

Mr. Morton, Solaris and SunOS were around long before Mr. Torvalds buyed it´s first 386. So, when you really want to talk about fragmentation, please look in the nearest mirror. But this discussion is nonsensical: There is no fragmentation in a world, where the next binary is just one makefile away. It doesn´t fragment the non-windows world, it eats away the Linux adressable market. And this is a huge difference.

So, why do they isssue such bold statements. In my opinion, Opensolaris is the most dangerous competitor for Linux in the open source based economy. At least from my point of view, i see many die-hard-linux shop that consider Solaris or Opensolaris. The luminaries of Linux are quite aware of this fact. Futhermore, there are some technical like ZFS or dtrace developments, where Linux can´t participate, because of the license they use (it´s a GPL problem, not a problem of the CDDL, as the BSDs or MacOS X can use Opensolaris technology).

When you look at Opensolaris and Linux, they seem to be mirror universes. Similar, but with important differences: Both are open-source, but as Linux thrives to broaden it´s common of code, Solaris licence was designed to include legacy components and to enable IP-based business with open source. Where Linux has no roadmap, Solaris and Opensolaris have one (can be advantageous as well as disadvantageous) . Linux development and integration in the mainline kernel is driven by the kernel maintainers, whereas Solaris has an full-fledged process to ensure such things like compatibility. Solaris is different enough to attract developers and nobody can really predict the outcome on a five year basis. Both opinopns are perfectly valid. And the communities will decide. By the way: Solaris has a big advantage, Sun is commited to it´s operating system. Linux has such "commited" backers like IBM, which pray Linux and sell AIX ... sorry, could not resist ...

And as a sidenote to the ever-reoccuring "Linux has more drivers" disccusion: In a market, where the newest graphic boards outdates faster than you can pass it over the counter, the advantage of having more hardware drivers can be a very temporary one.

Interesting annotation about the fuss surrounding the CFS in Linux:

I find it interesting and slightly sad, given how low level a topic this really is, how much is being written about the new CFS scheduler being introduced into Linux. The sad part is how much flamage is flying around as a result of this from people not in the slightest bit involved in the desgin and development - this sadly is the ugly side of many open source groups.

You should read the blog entry of to read the perception of one of the DTrace developers regarding the relationship of DTrace and Systemtap. But i really think the whole issue opens up the view to a different problem inside of Linux: The "not invented here (NIH)" problem. Linux isn´t immune to that problem.

The support for logical domains made it into the 2.6.23 linux kernel. Wow, this was really fast ...

Dave Miller announced, that he ported Linux as a guest to the LDOM environment.Some parts are still missing, but hey ... it´s the first version ...

I was tempted to write a harsh article about this comment from Mr. Torvalds, but Jonathan articulates my thoughts in his recent blog entry much better than i could.

Microsoft states, that Linux violates 235 of their patents. I assume, that this number is greatly exaggerated. But: Even when your enemy has 235 bullets, one is sufficient to kill you. And the interesting question is: Can you dodge 235 bullets? Interesting times ahead.

There even seems to be a raging cold war regarding this topic. Roger Parlof of Fortune wirtes in Microsoft takes on the free world:

So if Microsoft ever sued Linux distributor Red Hat for patent infringement, for instance, OIN might sue Microsoft in retaliation, trying to enjoin distribution of Windows. It's a cold war, and what keeps the peace is the threat of mutually assured destruction: patent Armageddon - an unending series of suits and countersuits that would hobble the industry and its customers.

This one is to good too leave it in the comments: Val Henson coauthored the ChunkFS paper, which states:

A few file systems, such as ZFS[2], have gone as far as checksumming and duplicating all file system metadata, which reduces the frequency of fsck but not the overall time.

According to her resume this seems to be the same person who stated in 2004 in her very own blog:

The on-disk state is always valid. No more fsck, no need to replay a journal. We use a copy-on-write, transactional update system to correctly and safely update data on disk. There is no window where the on-disk state can be corrupted by a power cycle or system panic. This means that you are much less likely to lose data than on a file system that uses fsck or journal replay to repair on-disk data corruption after a crash. Yes, supposedly fsck-free file systems already exist - but then explain to me all the time I've spent waiting for fsck to finish on ext3 or logging UFS - and the resulting file system corruption.

Kudos to Chad for pointing me to this one ...

It´s a well known problem in the computer industry, that the needed time for filesystem checking will reach sooner or later unacceptable dimensions. This was one reason, why we developed ZFS. A number of mechanisms in the filesystem ensures an always consistent state. The Linux community sees this problem as well.

But this solution looks more like a kludge: ChunkFS divides a filesystem into up to 256 chunks that gets transparently merged into one user/application-visible filesystem. Every chunk is an filystem on it´s own. The idea behind this concept is, that you only need to check a few chunks and not the whole filesystem. This idea has some major drawbacks. At first i assume that in practice the fault isolation of chunkfs won´t reach the level you need to save substantial fscking time.

It´s only a short thoughtgame, but: The more write load you give to the filesystem the more chunks will be in "dirty state". The more write load you have on a filesystem, the more probable a inconsistent state will be, as the probability of disrupting an write operation in progress rises with the amount of write operations. So in my personal opinion you end with several "dirty" chunks and thus you won´t get such an big advantage. The more you need the mechanisms to shorten fsck time, the less ChunkFS would help you.

The biggest advantage may be parallel fsck-ing of the chunks but this would pose a hge load to the storage systems although it would be interesting how to solve the dependencies between chunk (Imagine: Chunk A needs a consistent Chunk B, Chunk B needs a consistent Chunk A. How to solve this conflict without risking consistency of the whole filesystem) . Besides of this, it introduces new classes of problems like the creation of unique inodes over several file systems or the mentioned problem of interchunk dependencies.

At the end, there is only one solution to problem of the growing fsck run times: Obsoleting filesystem checking at all. The most reasonable way to to this is by copy on write and transactional writes. Net Apps saw the problem and invented WAFL, Sun saw the problem and invented ZFS. I think it´s time for the Linux community to find a real solution and to step back of developing an questionable kludge.

PS: The section 8 of this shows a problem that seems to be common within the Linux development community: Vast misunderstandings about the inner function of ZFS. There is no filesytem checking at ZFS, as the filesystem don´t need one, so . You can scrub the filesystem (in the widest and farthest sense similar to fsck, but this can be done online and it checks the validity of data and metadata by the checksums). As the people in the linux community tend to be intelligent to downright brilliant, i don´t understand this misunderstandings ...