File Systems and Storage

Vol. 5 No. 6 – September/October 2007

File Systems and Storage

Interviews

A Conversation with Jeff Bonwick and Bill Moore

This month ACM Queue speaks with two Sun engineers who are bringing file systems into the 21st century. Jeff Bonwick, CTO for storage at Sun, led development of the ZFS file system, which is now part of Solaris. Bonwick and his co-lead, Sun Distinguished Engineer Bill Moore, developed ZFS to address many of the problems they saw with current file systems, such as data integrity, scalability, and administration. In our discussion this month, Bonwick and Moore elaborate on these points and what makes ZFS such a big leap forward.

A Conversation with Jeff Bonwick and Bill Moore

The future of file systems

This month ACM Queue speaks with two Sun engineers who are bringing file systems into the 21st century. Jeff Bonwick, CTO for storage at Sun, led development of the ZFS file system, which is now part of Solaris. Bonwick and his co-lead, Sun Distinguished Engineer Bill Moore, developed ZFS to address many of the problems they saw with current file systems, such as data integrity, scalability, and administration. In our discussion this month, Bonwick and Moore elaborate on these points and what makes ZFS such a big leap forward.

Also in the conversation is Pawel Jakub Dawidek, a FreeBSD developer who successfully ported ZFS to FreeBSD. Ports to other operating systems, such as Mac OS X, Linux, and NetBSD are already under way, and his experience could pave the way for even wider adoption of ZFS.

Opinion

From Here to There, the SOA Way

SOA is no more a silver bullet than the approaches which preceded it. Back in ancient times, say, around the mid '80s when I was a grad student, distributed systems research was in its heyday. Systems like Trellis/Owl and Eden/Emerald were exploring issues in object-oriented language design, persistence, and distributed computing. One of the big themes to come out of that time period was 'location transparency', the idea that the way that you access an object should be independent of where it is located. That is, it shouldn't matter whether an object is in the same process, on the same machine in a different process, or on another machine altogether. Syntactically, the way that I interact with that object is the same; I'm just invoking a method on the object.

From Here to There, The SOA Way

SOA is no more a silver bullet than the approaches which preceded it.

Terry Coatta, Vitrium Systems

Back in ancient times, say, around the mid '80s when I was a grad student, distributed systems research was in its heyday. Systems like Trellis/Owl and Eden/Emerald were exploring issues in object-oriented language design, persistence, and distributed computing. One of the big themes to come out of that time period was location transparency—the idea that the way that you access an object should be independent of where it is located. That is, it shouldn't matter whether an object is in the same process, on the same machine in a different process, or on another machine altogether. Syntactically, the way that I interact with that object is the same; I'm just invoking a method on the object.

Now the people who were building those systems realized that there were inherent differences in performance associated the different locations at which an object could reside. There were a number of ways that one could address this problem. The simplest tactic was to assume that, despite the syntactic advantages of location transparency, the software developer would have to understand where objects were located and code accordingly. For example, if an object was known to be remote, the developer wouldn't execute a series of fine-grain invocations against it. Needless to say, there was something vaguely unsatisfying about this. The more satisfying, and unfortunately more complex, route was to create a caching infrastructure that would mask latency concerns. For example, the first time that a method was invoked on a remote object, the system would actually transfer some or all of the state of that object to the local system. Subsequent invocations on that object could then potentially be served very quickly from that cached data. Had this caching problem been easy to solve, we'd probably be using systems like that today. Alas, it is not an easy problem, due to issues such as cache invalidation, partial failures, etc.

by Terry Coatta

Ground Control to Architect Tom...

Project managers love him, recent software engineering graduates bow to him, and he inspires code warriors deep in the development trenches to wonder if a technology time warp may have passed them by. How can it be that no one else has ever proposed software development with the simplicity, innovation, and automation being trumpeted by Architect Tom? His ideas sound so space-age, so futuristic, but why should that be so surprising? After all, Tom is an architecture astronaut!

Ground Control to Architect Tom…

Can you hear me?

Alex Bell, The Boeing Company

Project managers love him, recent software engineering graduates bow to him, and he inspires code warriors deep in the development trenches to wonder if a technology time warp may have passed them by. How can it be that no one else has ever proposed software development with the simplicity, innovation, and automation being trumpeted by Architect Tom? His ideas sound so space-age, so futuristic, but why should that be so surprising? After all, Tom is an architecture astronaut!1

Architecture astronauts such as Tom naturally think at such high levels of innovation because they spend much of their time in high orbit where low oxygen levels counterbalance the technological shackles imposed by reality.

by Alex Bell

Articles

Hard Disk Drives: The Good, the Bad and the Ugly!

HDDs (hard-disk drives) are like the bread in a peanut butter and jelly sandwich—sort of an unexciting piece of hardware necessary to hold the “software.” They are simply a means to an end. HDD reliability, however, has always been a significant weak link, perhaps the weak link, in data storage. In the late 1980s people recognized that HDD reliability was inadequate for large data storage systems so redundancy was added at the system level with some brilliant software algorithms, and RAID (redundant array of inexpensive disks) became a reality. RAID moved the reliability requirements from the HDD itself to the system of data disks. Commercial implementations of RAID range from n+1 configurations (mirroring) to the more common RAID-4 and RAID-5, and recently to RAID-6, the n+2 configuration that increases storage system reliability using two redundant disks (dual parity). Additionally, reliability at the RAID group level has been favorably enhanced because HDD reliability has been improving as well.

HARD DISK DRIVES

THE GOOD, THE BAD AND THE UGLY

JON ELERATH, NETWORK APPLIANCE

HDDs (hard-disk drives) are like the bread in a peanut butter and jelly sandwich—sort of an unexciting piece of hardware necessary to hold the “software.” They are simply a means to an end. HDD reliability, however, has always been a significant weak link, perhaps the weak link, in data storage. In the late 1980s people recognized that HDD reliability was inadequate for large data storage systems so redundancy was added at the system level with some brilliant software algorithms, and RAID (redundant array of inexpensive disks) became a reality. RAID moved the reliability requirements from the HDD itself to the system of data disks. Commercial implementations of RAID range from n+1 configurations (mirroring) to the more common RAID-4 and RAID-5, and recently to RAID-6, the n+2 configuration that increases storage system reliability using two redundant disks (dual parity). Additionally, reliability at the RAID group level has been favorably enhanced because HDD reliability has been improving as well.

Seagate and Hitachi both have announced plans to ship one-terabyte HDDs by the time this article appears.1 With higher areal densities, lower fly-heights (the distance between the head and the disk media), and perpendicular magnetic recording technology, can HDD reliability continue to improve? The new technology required to achieve these capacities is not without concern. Are the failure mechanisms or the probability of failure any different from predecessors? Not only are there new issues to address stemming from the new technologies, but also failure mechanisms and modes vary by manufacturer, capacity, interface, and production lot.

by Jon Elerath

Opinion

Only Code Has Value?

A recent conversation about development methodologies turned to the relative value of various artifacts produced during the development process, and the person I was talking with said: the code has "always been the only artifact that matters. It's just that we're only now coming to recognize that." My reaction to this, not expressed at that time, was twofold. First, I got quite a sense of déjà-vu since it hearkened back to my time as an undergraduate and memories of many heated discussions about whether code was self-documenting. Second, I thought of several instances from recent experience in which the code alone simply was not enough to understand why the system was architected in a particular way.

Only Code Has Value?

Even the best-written code can't reveal why it's doing what it's doing.

Terry Coatta, Vitrium Systems

A recent conversation about development methodologies turned to the relative value of various artifacts produced during the development process, and the person I was talking with said: the code has "always been the only artifact that matters. It's just that we're only now coming to recognize that." My reaction to this, not expressed at that time, was twofold. First, I got quite a sense of déjà-vu since it harkened back to my time as an undergraduate and memories of many heated discussions about whether code was self-documenting. Second, I thought of several instances from recent experience in which the code alone simply was not enough to understand why the system was architected in a particular way.

Contrary to the point the speaker was making, the notion that code is all that matters has a long history in software development. In my experience, really good programmers have always tended towards the idea that code is self-sufficient. In fact, the ability to look at a piece of code and perceive its overall structure and purpose without recourse to comments or design documents has often been the informal way to separate the best from the rest. To paraphrase a theme from my undergraduate days: "If you don't understand my code, it doesn't mean that it needs comments, it means you need to learn more about programming."

by Terry Coatta

Articles

Standardizing Storage Clusters

Data-intensive applications such as data mining, movie animation, oil and gas exploration, and weather modeling generate and process huge amounts of data. File-data access throughput is critical for good performance. To scale well, these HPC (high-performance computing) applications distribute their computation among numerous client machines. HPC clusters can range from hundreds to thousands of clients with aggregate I/O demands ranging into the tens of gigabytes per second.

Standardizing Storage Clusters

Will pNFS become the new standard for parallel data access?

GARTH GOODSON, SAI SUSARLA, and RAHUL IYER, NETWORK APPLIANCE

Data-intensive applications such as data mining, movie animation, oil and gas exploration, and weather modeling generate and process huge amounts of data. File-data access throughput is critical for good performance. To scale well, these HPC (high-performance computing) applications distribute their computation among numerous client machines. HPC clusters can range from hundreds to thousands of clients with aggregate I/O demands ranging into the tens of gigabytes per second.

To simplify management, data is typically hosted on a networked storage service and accessed via network protocols such as NFS (Network File System) and CIFS (Common Internet File System). For scalability, the storage service is often distributed among multiple nodes to leverage their aggregate compute, network, and I/O capacity. Traditional network file protocols, however, restrict clients to access all files in a file system through a single server node. This prevents a storage service from delivering its aggregate capacity to clients on a per-file basis and limits scalability. To circumvent the single-server bottleneck of traditional network file system protocols, designers of clustered file services are faced with three choices (these are illustrated in figure 1):

by Garth Goodson, Sai Susharla, Rahul Iyer

Storage Virtualization Gets Smart

Over the past 20 years we have seen the transformation of storage from a dumb resource with fixed reliability, performance, and capacity to a much smarter resource that can actually play a role in how data is managed. In spite of the increasing capabilities of storage systems, however, traditional storage management models have made it hard to leverage these data management capabilities effectively. The net result has been overprovisioning and underutilization. In short, although the promise was that smart shared storage would simplify data management, the reality has been different.

Storage Virtualization Gets Smart

The days of overprovisioned, underutilized storage resources might soon become a thing of the past.

KOSTADIS ROUSSOS, NETWORK APPLIANCE

Over the past 20 years we have seen the transformation of storage from a dumb resource with fixed reliability, performance, and capacity to a much smarter resource that can actually play a role in how data is managed. In spite of the increasing capabilities of storage systems, however, traditional storage management models have made it hard to leverage these data management capabilities effectively. The net result has been overprovisioning and underutilization. In short, although the promise was that smart shared storage would simplify data management, the reality has been different.

To address the real challenges of data management and the shortcomings of traditional storage management, we propose a new data management framework based on three observations:

by Kostadis Roussos

Curmudgeon

The Code Delusion

No, I’m not cashing in on that titular domino effect that exploits best sellers. The temptations are great, given the rich rewards from a gullible readership, but offset, in the minds of decent writers, by the shame of literary hitchhiking. Thus, guides to the Louvre become The Da Vinci Code Walkthrough for Dummies, milching, as it were, several hot cows on one cover. Similarly, conventional books of recipes are boosted with titles such as The Da Vinci Cookbook—Opus Dei Eating for the Faithful. Dan Brown’s pseudofiction sales stats continue to amaze, cleverly stimulated by accusations of plagiarism and subsequent litigation (Dan found not guilty). One strange side effect of his book’s popularity and ubiquity is to hear the title shortened in conversations such as this overheard at a Microsoft cafeteria:

The Code Delusion

Stan Kelly-Bootle, Author

The real, the abstract, and the perceived

No, I’m not cashing in on that titular domino effect that exploits best sellers. The temptations are great, given the rich rewards from a gullible readership, but offset, in the minds of decent writers, by the shame of literary hitchhiking. Thus, guides to the Louvre become The Da Vinci Code Walkthrough for Dummies, milching, as it were, several hot cows on one cover. Similarly, conventional books of recipes are boosted with titles such as The Da Vinci Cookbook—Opus Dei Eating for the Faithful. Dan Brown’s pseudofiction sales stats continue to amaze, cleverly stimulated by accusations of plagiarism and subsequent litigation (Dan found not guilty). One strange side effect of his book’s popularity and ubiquity is to hear the title shortened in conversations such as this overheard at a Microsoft cafeteria:

“Surely you’ve read The Code?”

by Stan Kelly-Bootle

Kode Vicious

The Next Big Thing

Dear KV, I know you did a previous article where you listed some books to read (Kode Vicious Bugs Out, April 2006). I would also consider adding How to Design Programs, available free on the Web (http://www.htdp.org/). This book is great for explaining the process of writing a program. It uses the Scheme language and introduces FP (functional programming). I think FP could be the future of programming. John Backus of the IBM Research Laboratory suggested this in 1977 (http://www.stanford.edu/class/cs242/readings/backus.pdf). Even Microsoft has yielded to FP by introducing FP concepts in C# with LINQ (Language Integrated Query). Do you feel FP has a future in software development, or are we stuck with our current model of languages with increasing features?

The Next Big Thing

A koder with attitude, KV answers your questions. Miss Manners he ain’t.

This month Kode Vicious considers the future of functional programming and then offers up his top five protocol-design tips. Enjoy! And then send your own code-related questions to kv@acmqueue.com. We’ll thank you with an authentic Queue tchotchke.

by George Neville-Neil

Interviews

Orienting Oracle

As vice president of server technologies for Oracle, Amlan Debnath is one of the few people who can synthesize Oracle's software infrastructure plans. In an interview with ACM Queucast host Mike Vizard, Debnath provides some insights to how Oracle's strategy is evolving to simultaneously embrace service-oriented architectures alongside the demands of new and emerging events-driven architectures.

As vice president of server technologies for Oracle, Amlan Debnath is one of the few people who can synthesize Oracle's software infrastructure plans. In an interview with ACM Queucast host Mike Vizard, Debnath provides some insights to how Oracle's strategy is evolving to simultaneously embrace service-oriented architectures alongside the demands of new and emerging events-driven architectures.

Instant Legacy

Companies building applications in an SOA environment must take care to ensure seamless interaction and make certain that any changes to their applications won't negatively impact other applications. In an interview with ACM Queuecast host Mike Vizard, John Michelsen, CTO of iTKO, a Dallas based provider of testing tools for SOA applications, discusses the need for companies to recognize this delicate balance.

Companies building applications in an SOA environment must take care to ensure seamless interaction and make certain that any changes to their applications won't negatively impact other applications. In an interview with ACM Queuecast host Mike Vizard, John Michelsen, CTO of iTKO, a Dallas based provider of testing tools for SOA applications, discusses the need for companies to recognize this delicate balance.