Rubénerd!

To drastically improve virtual drive performance of qemu guests, create images with metadata preallocation:

% qemu-img create -f qcow2 -o size=2147483648,preallocate=metadata disk.qcow2

Then if you're on Linux, use fallocate to preallocate space:

% fallocate -l 2147483648 disk.qcow2

Passing this on for what it may be worth, they both saved me a lot of time copying files this morning. :)

The easiest method (from experimentation this evening!) is to use the e2label command. For example, to set the label of the first partition on the /dev/sdc drive:

# e2label /dev/sdc1 yournewlabel

At this rate, I'm thinking I should just start another site for just Linux tips. Nah ;D

I don't play many games, I prefer working on projects and blogging personally :). So when a friend of mine wanted to install Steam on my Mac Pro, it was more than willing to accommodate my wishes by not installing.

The procedure on not working

1. When installed in /Applications, complain when it discovers the file system is set to case-sensitive HFS+.

2. When installed in a virtual disk image formatted with case-insensitive HFS+, complain when it installs its Application Data files in the user's Library folder, which is of course located on the aforementioned case-sensitive HFS+ file system.

3. When a symbolic link is created between the Steam data folder and a folder on the disk image to accommodate these two problems:

% cd ~/Library/Application Data
% ln -s /Volumes/SteamStuff/Steam ./Steam

... then take an age to load, and finally crash.

Verdict

So it seems Steam and most Adobe products refuse to run on case-sensitive file systems, and many of my *nix software either prefer or mandate they run on case-sensitive file systems. No prises for guessing which I choose to accommodate!

That's not to say I'm not glad other Mac users with more orthodox file system and software choices are able to play games, just personal preference.

One of the questions I'm most often asked by people moving to Mac (the latest is my dad!) is whether or not their new Mac can read their external hard drives and memory keys. To save myself typing long responses every time, I'm creating this post instead.

The short answer is: YES your Mac can READ Windows formatted drives with no problems. The problem is writing.

Modern versions of Windows format drives either as FAT32 or NTFS:

FAT32

Can be read and written to by Macs but because it's older it only supports drives up to a certain file size. Most USB memory keys use this.

NTFS

Is more robust and reliable and is used by most external hard drives now. Macs can only read not write such volumes out of the box, but if you download and install the NTFS-3G project drivers you'll be able to write without problems.

Grilled Cheese Sandwich

I've never been able to get Windows or Mac OS X read or write to a grilled cheese sandwich, but I intend to start a SourceForge project to accomplish this once I get a $50,000 grant to develop it. If anyone here is willing to sponsor me with this, feel free to contact me.

By nearly all accounts my decision last year to adopt FreeBSD over Linux (and Windows... haha) on my non-Apple computers has been a damned good one. Installing, maintaining and updating FreeBSD boxes is so simple compared to Linux, the documentation is second to none, the FreeBSD Ports System is simple and easy to optimise, and I've really come to appreciate the clean drive layout.

There's just one problem! Living in Malaysia power spikes tend to happen more often than in Singapore and Australia, and while it's great that my surge protectors do a fine job of preventing any real damage (touch wood) I find myself turning computers back on that have been automatically switched off every couple of weeks. Let's just say I've become fairly well aquainted with fsck.

And therein lies the problem: FreeBSD's UFS doesn't have native journaling, so hard disk failures are far more of a pain in the arse to recover from. In comparison, Linux, Solaris and Mac OS X all have journaling meaning that if they ever fail it's a breeze to get them back up again after restarting.

Fortunately a cursory search on Google and Yahoo revealed a project called GJournal created by Pawel Jakub Dawidek during the Summer of Code 2005, which seems to be implementing journaling over exiting disk labels.

From the Journaling UFS with gjournal entries on the FreeBSD mailing list:

GJournal was designed to journal GEOM providers, so it actually works
below file system layer, but it has hooks which allow to work with
file systems. In other words, gjournal is not file system-depended,
it can work probably with any file system with minimum knowledge
about it. I implemented only UFS support.

And from the (outdated) article on the FreeBSD wiki:

Gjournal is a layer in the GEOM hierarchy that consumes two lower-layer devices and produces one device. The two lower-layer devices are called data disk and journal disk. The data disk is self-sufficient and (eventually) contains verbatim data that's handled to the layer, so after the journal is disconnected it in itself can be used as a normal storage device. The journal disk contains linear records for every write request handled to the layer

From what I can tell it has been released to the -CURRENT branch which doesn't help me sitting on -STABLE (and -RELEASE on my firewall box), but it appears it will be released in FreeBSD 7. Good to see this is happening; perhaps I'll install it seperately myself and give it a shot.

Has anyone had any success with this? It would seriously save me a lot of trouble.