Although I obviously had nothing to do with Google’s decision vis-a-vis China, having only started working there for a week, I was definitely glad to see it and it made me proud to be able to say that I work there. Kudos to Google’s management team for having made (IMHO) the right decision. Hopefully Yahoo and Microsoft will consider carefully what the ethical implications of their collusion and collaboration with the Chinese government’s attempt to control free speech and the human rights implications of the same.

Amazon can reach in and randomly destroy the books on your Kindle remotely over Whispernet, without asking your permission first. Well, technically, thanks to the terms and conditions that you have to agree to before you buy the Kindle, you gave them permission in advance. Well, no thanks. I think the Sony e-Reader is a much better choice as a result. Yet another reason why people should Just Say No to DRM.

After reading the comments on my earlier post, Delayed allocation and the zero-length file problemas well as some of the comments on the Slashdot storyas well as the Ubuntu bug, it’s become very clear to me that there are a lot of myths and misplaced concerns about fsync() and how best to use it. I thought it would be appropriate to correct as many of these misunderstandings about fsync() in one comprehensive blog posting.

A recent Ubuntu bughas gotten slashdotted, and has started raising a lot of questions about the safety of using ext4. I’ve actually been meaning to blog about this for a week or so, but between a bout of the stomach flu and a huge todo list at work, I simply haven’t had the time. The essential “problem” is that ext4 implements something called delayed allocation. Delayed allocation isn’t new to Linux; xfs has had delayed allocation for years.

On occasion, you will see the advice that the ext3 file system is not suitable for Solid State Disks (SSD’s) due to the extra writes caused by journaling — and so Linux users using SSD’s should use ext2 instead. However, is this folk wisdom actually true? This weekend, I decided to measure exactly what the write overhead of journaling actually is in actual practice. For this experiment I used ext4, since I recently added a feature to track the amount of writes to the file system over its lifetime (to better gauge the wear and tear on an SSD).

Last night I managed to finish up a rather satisfying improvement to ext4’s inode and block allocators. The ext4’s original allocator was actually a bit more simple-minded than ext3’s, in that it didn’t implement the Orlov algorithm to spread out top-level directories for better filesystem aging. It also was buggy in certain ways, where it would return ENOSPC even when there were still plenty of inodes in the file system.

I came across the following from the ext3-users mailing list. The poor user was stuck on a never-updated RHEL 3 production server and running into kernel panic problems. He was advised to try updating to the latest kernel rpm from Red Hat, but he didn’t feel he could do that. In his words: I’m caught between a rock and a hard place due to the EMC PowerPath binary only kernel crack.

Last week, Scott James Remnant posted a series of “Git Sucks” on his blog, starting with this one here, with follow up entries hereand here. His problem? To quote Scott, “I want to put a branch I have somewhere so somebody else can get it. That’s the whole point of distributed revision-control, collaboration.” He thought this was a “mind-numbingly trivial” operation, and was frustrated when it wasn’t a one-line command in git.

In one of the comments to my last blog entry, an anonymous commenter writes: You seem to be taking a different perspective to linus on the “adapting to the the disk technology” front (Linus seems to against having to have the OS know about disk boundaries and having to do levelling itself) That’s an interesting question, and I figure it’s worth its own top-level entry, as opposed to a reply in the comment stream.

I recently purchased a new toy, an Intel X25-M SSD, and when I was setting it up initially, I decided I wanted to make sure the file system was aligned on an erase block boundary. This is a generally considered to be a Very Good Thing to do for most SSD’s available today, although there’s some question about how important this really is for Intel SSD’s — more on that in a moment.