Once again, there’s been another story about how Google is having trouble retaining talent.   Despite all Eric Schmidt’s attempts to tell folks that Google’s regretted attrition rate has not changed in seven years, this story just doesn’t want to seem to die.   (And those stories about Google paying $3.5 million and $7 million to keep an engineer from defecting to Facebook?   As far as I know, total bull.  I bet it’s something made up by some Facebook recruiter who needed to explain how she let a live prospect get away.  🙂

At least for me, the complete opposite is true.   There are very few companies where I can do the work that I want to do, and Google is one of them.   A startup is totally the wrong place for me.   Why?  Because if you talk to any venture capitalist, a startup has one and only one reason to exist: to prove that it has a scalable, viable business model.   Take diapers.com for example.   As Business Week described, while they were proving that they had a business model that worked, they purchased their diapers at the local BJ’s and shipped them via Fedex.   Another startup, Chegg, proved its business model by using Amazon.com to drop ship text books to their first customers.  (The venture capitalist Mark Maples talked about this in a brilliant talk at the Founders Showcase; the Chegg example starts around 20:50 minutes in, but I’d recommend listening to the whole thing, since it’s such a great talk.)   You don’t negotiate volume discounts with textbook publishers, or build huge warehouses to hold all of the diapers that you’re going to buy until you prove that you have a business model that works.

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.

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.

At the Linux Foundation, I recently had been brainstorming with some my colleagues about ways in which we might be able to reach out to the various local Linux User’s Group (LUGS). So I was quite surprised when I saw a blog posting from Lenovo’s Connections blog asking the question: “Local User Groups – gone the way of the dinosaur?”and even more provocatively, “Has the web now relegated the user group to history, along with dot matrix printers, cassette tapes for mass storage, and dial up modems with acoustic couplers?

Given the recent brouhaha in Debian, and General Resolution regarding Lenny’s Release policy as it relates to Firmware and Debian’s Social Contract, which has led to the resignation of Manoj Srivastava from the position of Secretary for the Debian Project, I’m reminded of the following passage from Gordon Dickson’s Tactics of Mistakes (part of Dickson’s Childe Cycle, in which he tells the story of the rise of the Dorsai): “No,” said Cletus.