23-09-2014, 02:14 PM
The Zettabyte File System
The Zettabyte.pdf (Size: 178.64 KB / Downloads: 26)
1 Introduction
Upon hearing about our work on ZFS, some people
appear to be genuinely surprised and ask, “Aren’t
local file systems a solved problem?” From this
question, we can deduce that the speaker has
probably never lost important files, run out of
space on a partition, attempted to boot with a
damaged root file system, needed to repartition a
disk, struggled with a volume manager, spent a
weekend adding new storage to a file server, tried
to grow or shrink a file system, mistyped something
in /etc/fstab, experienced silent data corruption,
or waited for fsck to finish. Some people are lucky
enough to never encounter these problems because
they are handled behind the scenes by system
administrators. Others accept such inconveniences
as inevitable in any file system. While the last
few decades of file system research have resulted
in a great deal of progress in performance and
recoverability, much room for improvement remains
in the areas of data integrity, availability, ease of
administration, and scalability
The Storage Pool Allocator
The Storage Pool Allocator (SPA) allocates blocks
from all the devices in a storage pool. One system
can have multiple storage pools, although most
systems will only need one pool. Unlike a volume
manager, the SPA does not present itself as a
logical block device. Instead, it presents itself as
an interface to allocate and free virtually addressed
blocks — basically, malloc() and free() for disk
space. We call the virtual addresses of disk blocks
data virtual addresses (DVAs). Using virtually
addressed blocks makes it easy to implement several
of our design principles. First, it allows dynamic
addition and removal of devices from the storage
pool without interrupting service. None of the
code above the SPA layer knows where a particular
block is physically located, so when a new device
is added, the SPA can immediately start allocating
new blocks from it without involving the rest of
the file system code. Likewise, when the user
ZFS in action
All of this high-level architectural stuff is great,
but what does ZFS actually look like in practice?
In this section, we’ll use a transcript (slightly
edited for two-column format) of ZFS in action to
demonstrate three of the benefits we claim for ZFS:
simplified administration, virtualization of storage,
and detection and correction of data corruption.
First, we’ll create a storage pool and several ZFS
file systems. Next, we’ll add more storage to the
pool dynamically and show that the file systems
start using the new space immediately. Then
we’ll deliberately scribble garbage on one side of a
mirror while it’s in active use, and show that ZFS
automatically detects and corrects the resulting
data corruption.
Conclusion
Current file systems still suffer from a variety of
problems: complicated administration, poor data
integrity guarantees, and limited capacity. The
key architectural elements of ZFS that solve these
problems are pooled storage, the movement of block
allocation out of the file system and into the storag
pool allocator, an object-based storage model,
checksumming of all on-disk blocks, transactional
copy-on-write of all blocks, and 128-bit virtual
block addresses. Our implementation was relatively
simple, especially considering that we incorporate