c0t0d0s0.org

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 ...

Mark Twain said once: "The reports of my death are greatly exaggerated". There are many pundits who proclaim the death of Unix, every year again for the last 10 years. But it seems, that this reports are greatly exaggerated, too. There is an report about an survey made with unix admins at the IT Jungle. The headline says it all: Unix Is Dead? It Isn't Even Sick. . .

Panchaleswar Nayak points to an interesting research paper about Writing Solaris Device Drivers in Java. I find this development very promising. You only have to write your drivers once for all platforms that implements the Squawk Java virtual machine. The next step to drive this concept would be the definition of an common generic interface between drivers and the operating system integrated in different operating systems outside the Solaris world. You would be able to use the same driver in different operating system without recompilation.

This would be great help in the competition against the windows ecosphere with their overhelming amount of drivers, as the fragmentation of the unix market from the look of driver developers would disappear.

Kris hat einen ein sehr guten Artikel über die Abläufe beim Starten und Beenden von Prozessen in einem unixoiden Operating Environment geschrieben: fork, exec, wait und exit. Eindeutige Leseempfehlung.

Gemessen an der Anzahl offener Shells auf meinem System bin ich wohl nicht der Standard-Mac-User. Und man mag es garnicht glauben, die Terminal.app von Mac OS X ist ganz brauchbar, auch wenn ich mittlerweile lieber iTerm verwende. Also gebt euch nicht auf, nutzt die Shell. Insofern freue mich ueber einen Neuzugang in der Blogosphere: Pimp my shell. Oder wie holt man mehr aus seiner Shell raus.

I found this text today, and even it´s not about Sun (not even a Sun product), it is nevertheless very interesting, because it paints an picture of our competition and put the wonderful picture IBM presents in it´s tv-commercials into perspective:

The need for manual repairs for frequent Linux server crashes "translated into wasted time and money and, in some cases, downtime for important applications," said Arty Ecock, manager of VM enterprise systems for CUNY Computing and Information Systems (CIS).

and

CUNY chose Red Hat Linux running on a single chassis of IBM blade servers to support these applications. Unfortunately, the servers had "laptop-quality IDE drives installed on each blade," said Ecock. "They would fail frequently." To fix each failure, CUNY's IT folks had to replace hard drives and provision the blades manually.

and

Servers didn't fail just once, either. "The hard drives in our blades were frequently burning out," Ecock said.

Unfortunatly they did not use the most obvious solution: Solaris 10 x86 with Jumpstart Enterprise Tookit. Deploying webservers with this solution is a piece of cake. Instead they use a rather mysterious netboot-solution.
Finally this points to one of weak points of linux: Whatever analysts or linux companies will tell you, nearly every commercial grade unix will make you more productive by better stability and better managebility . Commercial unixes had to crack some hart nuts in the past, nuts that still in front of the linux community. Kickstart or Autoyast are only the beginning, not the ultimate solution.
(PS: And no, the harddisks in Galaxy and T2000 are not laptop-grade disks, they are server-class SAS-disks.)