c0t0d0s0.org

Nice presentation about the most southern installation of SamFS: Ein Robot auf hoher See - SAM-FS bei 70 Grad Süd (sorry, only in german language, but nice photos). It´s about a SamFS installation on the Polarstern, a german research vessel. I found this presentation held by Dr. Hans Pfeiffenberger from the Alfred Wegener Institute for Polar and Marine Research after a hint from a colleague. This is storage under extreme conditions.

A fully automatic Triple-A goes berzerk and kills 9 soldier in south africa.

A robot cannon began wildly and autonomously firing its huge gun in South Africa last Friday, killing 9 soldiers and wounding 14. The Oerlikon GDF-005 antiaircraft gun suddenly began uncontrollably shooting as it swung back and forth, spraying hundreds of high-explosive 35mm cannon shells all over the place

This is a good example why software should never ever control the actual firing of bullets. In wartimes it may be a good tradeoff to design a trigger-happy robot for antimortar/antishell artillery, as it´s propable that more people are killed by mortar rounds then by a berzerk robot. But at peace time without incoming rounds? At least it wasn´t a wise choise to put live ammunition into this robot.

I´ve got some really good photos of the maiden flight of the A380 MSN11. You will find them at aviation.c0t0d0s0.org.(here and here

Ob Airbus jetzt wohl Ausparksensoren beim A380 nachruestet? Airbus A380 in Bangkok leicht beschädigt

Sometimes it looks like Boeing is the IBM of the aircraft industry: Bold statements galore, but nothing behind it . Interesting article at the Seattle Times : Boeing may acknowledge further 787 delays next week. I remember dozens of articles in the media who try to tell the world, that Boeing is so much better at constructing the 787 then Airbus at building the A380. But: The airframe of the 787 at rollout wasn´t able to fly, even when all other systems were in place and functional, because of temporary fasteners.

Boeing partly dismantled the first 787 immediately after its rollout to allow mechanics to install systems — including electrical wiring, hydraulic tubes and the flight-deck instrumentation — and also to replace temporary fasteners.

And according to other reports, switching on the power in the plane is still weeks away. I simply do not believe that they deliver their first 787 in May 2008. I would bet on May 2009. At the end, it´s like with the Power6 4.7 Ghz

A second A380 can be found here, even a A340 looks a little bit small in relation to the lady.
(found on Google Maps via Google Sightseeing)

Erstauslieferung der SIA-A380 ist am 15. Oktober. Vielleicht hören dann endlich mal die Unkenrufe auf ...

Two impressive points at this video: The landing with cross winds and the the sheer size of the lady ...

The Chicago Tribune speculates in "Takeoff appears delayed for 787" about delays due software problems. I don´t think, that the software will be the biggest problem of the 787. As far as i know, nobody has long-term experience with an large sized commercial aircraft consisting out of plastic. Until now all "plastic aircraft" were military ones, pulled into the hangar at night, relativly small time airborne and with a "no-matter-the-costs"-maintainance. But whats with an apron-parking aircraft, that rushes from one airport to another?

I´ve reported about the separated ZIL a few days ago. The problem of the described NVRAM PCI card is, that you can´t do a clusterfailover with such a device. How do you want to failover the seperate log, when the log is on a card in the failed server? Sun had a product called Prestoserve, that was used to accelerate NFS and DB. It was static RAM with a battery. It was great for benchmarks, but suffered by the cluster problem.

Thus you should use some external device, that can failover with the rest of your storage. The obvious choice would be a RAM-based Solid State Disk(SSD). But these are quite expensive: You need the RAM, you need a harddisk to keep the data persistent when power fails, and you need a rechargeable battery or an capacitor that´s able to power the SSD until all data is written to the hard disk.

A Flash-Based SSD would be a more sensible choice, as Flash is a non-volatile memory by nature. Such a disk costs you approximatly 400$. But most people think "Oh no, wear will destroy it within a few days". Experiences with el-cheapo CF-cards underline this assumption.

But let´s calculate with the specifications of a leading brand flash disk. Let´s assume: A 32 GB flash-based SSD is specified for 2.000.000 write cycles. We have a sustained stream of 40 MB per second (conservative assumption). The wear leveling is perfect (perhaps supported by a seperate ZIL algorithm, that looks at the flash SSD as a cyclic buffer). Okay, a little math:


So this flash SSD wouldn´t fail by wear within the usable live of the storage and the server, even when you write 40 MB every second to it. I´m sure, that a flash disk doesn´t run such a long time, but this is not a wear problem, it´s the problem, that modern electronic hasn´t the build quality of former times.

Based on this considerations, a flash SSD would be an interesting choice for the separated ZIL. Or at least: Wear isn´t a reason for not using Flash SSD

PS: There is one point, i´m not perfectly sure, but i interpret the 2 million write cycles as the ability to erase and write the full disk 2 million times.

Scientia writes in his blog about a little-reported fact: Albeit announced in 2006, a Core2Duo with more than 3 GHz is still not available.

Mads pointed me to this good article written by Greg regarding software patents:

Will we stop pursuing software patents on our software? Can't do that yet. That's simply because our competitors will still go for them, and unless our system changes, we'd have fewer "trading stamps" and end up paying even higher rates to indemnify the users of our software.

At the end, the patent systems gone wild somewhere in the past in the software space. Even when you don´t like it, you have to go for it, as other would do it. And nobody would step back first, as all participants are in fear that all other market participants would use this as the competitive weapon. It´s the classical mexican standoff.

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

I really like the presentations and talks of Greg Papadoplos, but his blog entry about "the five computing complexes" is a miss in a collection of hits by Greg.

At first the internet is a collection of humans, and not a collection of consumers. It´s the old unterstandig of a few broadcasting company which controls the access to the communication between people. This time is long gone.

I think, that in commercial applications we will see such an consolidation postulated by Greg. But as soon you take the consumer into consideration, you will see that he isn´t limited to the computing complexes. Google, Salesforce and Amazon are company. The are in the consumer focus today, but this is not a perpetual state. Customers are a very epheremal good.

The model of the complexes is the old economy of large enterprises. The internet will bring us a completly different model of economy. The economy of the future will be a fractal one. Today the single most successful application in Internet is fire sharing. It´s a service enabled by the existence of a vast amount system in the internet at various people. Okay, the actual form of this economy is based on illegal transactions, but this is only the cause, because nobody found a way to commercialize it.

It´s my strong believe that the future of internet bases economy lies in clearinghouses that enables the commercialisation of a peer-to-peer-economy. They don´t have products, they don´t have interest, what is selled. They sell only rights. Rights to use a pair of shoes, rights to hear music or rights to read a book or the right to use a service. The way of distribution is irrelevant. The future of internet will be a serverless one. Or to say it differently: It´s full of servers. Every system is a server.

At second, there would at least one additional computing complex. The Big Computer of Europe. Regarding data protection regulations the US and Europe could not be farther seperated than moon and earth.

Jon Stokes of ars.technica wrote a nice summary of the stuff already known about the next gen core dubbed K8L:A quick look at AMD's quad-core Barcelona.