Comments on: Our lackluster commodity file systems

By: Tom Warfel

Tom Warfel — Tue, 28 Aug 2007 22:10:03 +0000

That is a great thesis: Clean idea, testable hypothesis derived from that idea, and some good follow-on ideas for future work. Unfortunately, creating a reliable filesystem takes a lot of time, careful planning, and effort. (Witness the ReiserFS/3/4 saga. ) Starting from the working ixt3 code could be a good start. I haven’t been able to google sources for the prototype ixt3 driver. Has anyone seen a posted source online of the prototype IRON FS?

By: Robert Pearson

Robert Pearson — Sat, 11 Aug 2007 03:37:17 +0000

RE: [Storage Bits] “Maybe, someday, Microsoft will start measuring success in terms of software quality instead of market share”

Sounds good. Think about it.
Maybe software quality is in the eye of the beholder?
One beholders pleasure is another’s poison?
Maybe market share averages price/performance across the eyes of all beholders?

If the quality of the software falls below acceptable levels of the market it will disappear. Market history proves this.
Market history also proves that acceptable levels of quality can be abysmally low. Hence many products that should have died an early death live on and make money for the vendor who laugh and sing all the way to the bank. Because their personal livelihood doesn’t depend on the product or its level of quality. Only its acceptability.

Its like a valid test for parenting. Won’t happen.

By: Another Thought About Oracle Database 11g SecureFiles. « Kevin Closson’s Oracle Blog: Platform, Storage & Clustering Topics Related to Oracle Databases

Fri, 10 Aug 2007 23:13:15 +0000

[...] I was reading StorageMojo.com today where Robin was discussing the state of commodity filesystems and their (in)ability to properly deal with certain storage failures. The story seems even more grim than I was aware. I recommend you read the IRON paper and think about those LOBs. Oracle can do this stuff so much better. [...]

By: Anonymous

Anonymous — Fri, 10 Aug 2007 16:46:21 +0000

Part of the problem is detection of errors, correction when those errors occur and fatal failure. In most cases all I care about is that my filesystem is fast and survives a power outage. The disk failures I’ve seen have either been fatal (disk did not start) or the corruption so vast and obvious that restoration from backups was the only thing to be done. Bit flips will become more common but I’d much rather some background backup system (e.g. shadow volumes/snapshotting to somewhere else) than filesystem level checksumming and correction. Of it’s unlikely I’d detect bit flips in uncompressed data myself so maybe it’s always been happening… Additionally not everything is equally important on my disk…

(It’s also telling that this research was on Linux filesystems. The barrier to entry is low, there are several of them, you can change the code and the pay off high if your work is useful. Of course my question is – does the failure tested reflect how real disks fail?)