ZFS Bug From Solaris Found in Linux FUSE Version and Fixed

Those who know me in my day job know that I’m pretty good at breaking things, so I guess I shouldn’t be surprised I found a ZFS bug that was from the OpenSolaris code base and had been sitting there for about a year unnoticed. The ZFS on Linux developer has now fixed the bug and sent a patch back upstream, so hopefully there will be a fix in OpenSolaris because of work done on Linux!

The good thing is that because I found it on Linux running ZFS using FUSE the bug didn’t take my system down when the ZFS file system daemon died. 🙂 http://www.csamuel.org/2007/06/19/zfsfuse-makes-it-to-linuxworld-and-lwn/

Must Remember for Future ZFS on Linux Testing..

Linus added support for block device based filesystems into 2.6.20, so it’ll be interesting to see what (if any) effect on ZFS/FUSE it will have, especially given it’s named in the commit. 🙂

I never intended this, but people started using fuse to implement block device based “real” filesystems (ntfs-3g, zfs).

Looks like Ubuntu’s Feisty Fawn will ship with this as the 2.6.20 kernels in the development versions have the fuseblk filesystem showing up in /proc/filesystems once you’ve loaded the fuse module, and the fuse-utils package seems to support it too.

Update: Sadly it appears that this isn’t much use for ZFS. 🙁

BBC Asking Should New Service Be Microsoft Only ?

The BBC Trust is currently carrying out a consultation exercise into their new “On Demand” TV services over the Internet in which they ask “How important is it that the proposed seven-day catchup service be available to consumers who are not using Microsoft software ?” (see question 5).

The accompanying PDF says:

In respect of the seven-day catch-up over the internet service, the files would require DRM to ensure that they were appropriately restricted in terms of time and geographic consumption. The only system that currently provides this security is Windows Media 10 and above. Further, the only comprehensively deployed operating system that currently supports Windows Media Player 10 and above is the Windows XP operating system. As a result of these DRM requirements the proposed BBC iPlayer download manager element therefore requires Windows Media Player 10 and Windows XP. This means the service would be unavailable to a minority of consumers who either do not use Microsoft or do not have an up-to-date Microsoft operating system. However, over time, technology improvements are likely to enable even more efficient methods of delivery. Further, it is our understanding the BBC Executive are working towards the iPlayer download manager being able to function on other operating systems.

and go on to say:

We also note that the Microsoft-based strategy for rights management will limit usage. Normally, we would expect BBC services to be universally available, as universal access to BBC services is in the public interest. However, as set out above, other mainstream technology platforms do not currently provide the appropriate security.

So the BBC Trust do want greater usage, but don’t seem to understand that DRM will stop that even if people do have access to Windows.

People may want to make their feelings known on this..

(Via Alec)

Why You Should Fear Microsoft

There’s been an ongoing discussion on the Beowulf list for Linux clusters about SGI and Windows clusters (which I’ve not had a chance to read), but as part of it the inimitable Robert G. Brown (or one of his AI bots that he must use to keep up his prolific and ever useful posting rate) wrote a lengthy and very interesting piece about why he is, and others should, be afraid of Microsoft’s dominance. It is written in response to a posting from a Microsoft employee, which in itself is an interesting turn up.

He makes lots of references to “hydraulic monopolies”, so it is worth reading up on hydraulic empires for some background to the historical context.

One point he makes is about their impact on pension funds:

Finally, there is Microsoft and pension plans and the general stock market. This is perhaps the scariest part of Microsoft’s supermonopoly status, one that a gentleman named Bill Parrish seems to have devoted himself to uncovering and laying bare to an obviously uncaring world. Microsoft stock is a rather huge component of stock owned by both pension plans and individual “S&P Index” investors (and individuals) all over the world. If Microsoft stock were to collapse, or even to slip steadily down in nominal value, the economic consequences would be catastrophic. It would make the collapse of Enron look tame by comparison, because Microsoft is considerably larger at baseline than Enron ever was. This creates a HUGE disincentive for individuals and companies to challenge Microsoft’s hydraulic legacy — Microsoft has essentially tied the future well being and wealth of an entire generation of corporate employees and index fund investors to their own continued success.

Here he is using an essay by the afforementioned Bill Parish which was done as an editorial for Barrons (from the WSJ people) in 2003 and available online, where Mr Parish writes:

For anyone owning a S&P 500 index fund, Microsoft automatically was almost 4% of their investment. Microsoft’s stock has since declined 58.5%, from $58.38 a share on Dec. 31, 1999,(adjusted for a subsequent split) to $24.21 on March 31. That’s a loss of more than $363 billion, an amount exceeding the gross national product of all but a few nations. The loss also happens to be almost five times the total market value of Enron at its peak.

For reference, MSFT are currently trading at US$30.74 and a market capitalisation of US$302.19 billion. That’s about twice the GDP of Ireland and half the GDP of Australia.

Rob has kindly granted permission for its reproduction here, but he retains copyright.

Continue reading

Vacation 1.2.6.3 released

This is a minor bugfix release to the 1.2.6 series of Vacation inspired by looking at the sorts of things Linux distros patch for their own usage.

Vacation no longer builds as -m486 by default, though it will build as 32-bit on AMD64/EM64T because GDBM is not 32/64-bit portable and trying to run a 64-bit version against a 32-bit created GDBM causes it to fail and syslog a success message. This is sub-optimal.

The Makefiles CFLAGS handling has been tidied up a fair bit as a consequence and will hopefully make life a little easier for distributors and it no longer tries to strip the vaclook Perl script on install, which was very silly.

Vacation also now accepts the -i option as well as -I to initialise its database.

Download from SourceForge here.

Continue reading

Intel Development Tools on Debian & Debian Derived Linux Distributions

If you have an interest in being able to run the Intel developer tools (( the C & Fortran compilers, Vtune, etc )) under Debian or a Debian derived distribution such as Ubuntu then please sign up and make your views known on the Intel instigated poll on their forums, please!

At the moment they only support RPM based distributions (mainly RHEL and SLES) and whilst you can get the compilers going through some documented hacks getting Vtune to install is a real pain – the only way I’ve heard so far is this hack that involves having a machine running one of those distros to hand.

Intel make these tools available to people doing development on projects for no recompense (but be sure to read their FAQ on who does and doesn’t qualify).

ZFS Disk Mirroring, Striping and RAID-Z

This is the third in a series of tests (( the previous ones are ZFS on Linux Works! and ZFS versus XFS with Bonnie++ patched to use random data )), but this time we’re going to test out how it handles multiple drives natively, rather than running over an existing software RAID+LVM setup. ZFS has the ability to dynamically add disks to a pool for striping (the default) mirroring or RAID-Z (with single or double parity) which are designed to improve speed (with striping), reliability (with mirroring) and performance and reliability (with RAID-Z).

Continue reading

ZFS versus XFS with Bonnie++ patched to use random data

I’ve patched Bonnie++ (( it’s not ready for production use as it isn’t controlled by a command line switch and relies on /dev/urandom existing )) to use a block of data from /dev/urandom instead of all 0’s for its block write tests. The intention is to see how the file systems react to less predictable data and to remove the unfair advantage that ZFS has with compression (( yes, I’m going to send the patch to Russell to look at )).

Continue reading