Wiki code for Source Tour

Hide Line numbers
1: == ZFS Source Tour
2: 
3:  [[image:zfstour.png||alt="zfstour.png"]] [[[ odg ]>>attach:zfstour.odg]]
4: 
5: This page is designed to take users through a brief overview of the source code associated with the ZFS filesystem. It is not intended as an introduction to ZFS – it is assumed that you already have some familiarity with common terms and definitions, as well as a general sense of filesystem architecture.
6: 
7: Traditionally, we describe ZFS as being made of up of three components: ZPL (ZFS POSIX Layer), DMU (Data Management Unit), and SPA (Storage Pool Allocator). While this serves as a useful example for slideware, the real story is a little more complex. The following image gives a more detailed overview; clicking on one of the areas will take you to a more detailed description and links to source code.
8: 
9: In this picture, you can still see the three basic layers, though there are quite a few more elements in each. In addition, we show zvol consumers, as well as the management path, namely zfs(1M) and zpool(1M). You’ll find a brief description of all these subsystems below. This is not intended to be an exhaustive overview of exactly how everything works. In the end, the source code is the final documentation. We hope that it is easy to follow and well commented.If not, feel free to post to the [[ZFS discussion forum>>http://www.opensolaris.org/jive/forum.jspa?forumID=80]].
10: 
11: === Filesystem Consumers
12: 
13: These are your basic applications that interact with ZFS solely through the POSIX filesystem APIs. Virtually every application falls into this category. The system calls are passed through the generic OpenSolaris VFS layer to the ZPL.
14: 
15: === Device Consumers
16: 
17: ZFS provides a means to created ’emulated volumes’. These volumes are backed by storage from a storage pool, but appear as a normal device under {{code}}/dev{{/code}}. This is not a typical use case, but there are a small set of cases where this capability is useful. There are a small number of applications that interact directly with these devices, but the most common consumer is a kernel filesystem or target driver layered on top of the device.
18: 
19: === Management GUI
20: 
21: Solaris will ship with a web-based ZFS GUI in build 28. While not part of OpenSolaris (yet), it is an example of a Java-based GUI layered on top of the JNI.
22: 
23: === Management Consumers
24: 
25: These applications are those which manipulate ZFS filesystem or Storage pools, including examining properties and dataset hierarchy. While there are some scattered exceptions (zoneadm, zoneadmd, fstyp), the two main applications are zpool(1M) and zfs(1M).
26: 
27: ==== zpool(1M)
28: 
29: This command is responsible for creating and managing ZFS storage pools. Its primary purpose is to parse command line input and translate them into libzfs calls, handling any errors along the way. The source for this command can be found in [[usr/src/cmd/zpool>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zpool]]. It covers the following files:
30: 
31: |[[zpool_main.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zpool/zpool_main.c]]|The bulk of the command, responsible for processing all arguments and subcommands
32: |[[zpool_vdev.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zpool/zpool_vdev.c]]|Code responsible for converting a series of vdevs into an nvlist representation for libzfs
33: |[[zpool_iter.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zpool/zpool_iter.c]]|Code to iterate over some or all the pools in the system easily
34: |[[zpool_util.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zpool/zpool_util.c]]|Miscellaneous utility functions
35: 
36: ==== zfs(1M)
37: 
38: This command is responsible for creating and managing ZFS filesystems. Similar to zpool(1M), its purpose is really just to parse command line arguments and pass the handling off to libzfs. The source for this command can be found in [[usr/src/cmd/zfs>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zfs]]. It covers the following ilfes:
39: 
40: |[[zfs_main.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zfs/zfs_main.c]]|The bulk of the command, responsible for processing all arguments and subcommands
41: |[[zfs_iter.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zfs/zfs_iter.c]]|Code to iterate over some or all of the datasets in the system
42: 
43: === JNI
44: 
45: This library provides a Java interface to libzfs. It is currently a private interface, and is tailored specifically for the GUI. As such, it is geared primarily toward observability, as the GUI performs most actions through the CLI. The source for this library can be found in [[usr/src/lib/libzfs_jni>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs_jni]]
46: 
47: === libzfs
48: 
49: This is the primary interface for management apps to interact with the ZFS kernel module. The library presents a unified, object-based mechanism for accessing and manipulating both storage pools and filesystems. The underlying mechanism used to communicate with the kernel is ioctl(2) calls through /dev/zfs. The source for this library can be found in [[usr/src/lib/libzfs>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs]]. It covers the following files:
50: 
51: |[[libzfs_dataset.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_dataset.c]]|Primary interfaces for manipulating datasets
52: |[[libzfs_pool.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_pool.c]]|Primary interfaces for manipulating pool
53: |[[libzfs_changelist.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_changelist.c]]|Utility routines for propagating property changes across children
54: |[[libzfs_config.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_config.c]]|Read and manipulate pool configuration information
55: |[[libzfs_graph.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_graph.c]]|Construct dependent lists for datasets
56: |[[libzfs_import.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_import.c]]|Discover and import pools
57: |[[libzfs_mount.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_mount.c]]|Mount, unmount, and share datasets.
58: |[[libzfs_status.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_status.c]]|Link to FMA knowledge articles based on pool state
59: |[[libzfs_util.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_util.c]]|Miscellaneous routines
60: 
61: === ZPL (ZFS POSIX Layer)
62: 
63: The ZPL is the primary interface for interacting with ZFS as a filesystem. It is a (relatively) thin layer that sits atop the DMU and presents a filesystem abstraction of files and directories. It is responsible for bridging the gap between the OpenSolaris VFS interfaces and the underlying DMU interfaces. It is also responsible for enforcing ACL (Access Control List) rules as well as synchronous (O_DSYNC) semantics.
64: 
65: |[[zfs_vfsops.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_vfsops.c]]|OpenSolaris VFS interfaces
66: |[[zfs_vnops.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_vnops.c]]|OpenSolaris vnode interfaces
67: |[[zfs_znode.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_znode.c]]|Each vnode corresponds to an underlying znode
68: |[[zfs_dir.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_dir.c]]|Directory operations
69: |[[zfs_acl.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_acl.c]]|ACL implementation
70: |[[zfs_ctldir.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_ctldir.c]]|Pseudo filesystem implementation .zfs/snapshot
71: |[[zfs_log.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_log.c]]|ZPL interface to record intent log entries
72: |[[zfs_replay.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_replay.c]]|ZPL interface to replay intent log entries
73: |[[zfs_byteswap.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_byteswap.c]]|Byteswap routines for ZPL data structures
74: 
75: === ZVOL (ZFS Emulated Volume)
76: 
77: ZFS includes the ability to present raw devices backed by space from a storage pool. These are known as ’zvols’ within the source code, and is implemented by a single file in the ZFS source.
78: 
79: |[[zvol.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zvol.c]]|Volume emulation interface
80: 
81: === /dev/zfs
82: 
83: This device is the primary point of control for libzfs. While consumers could consume the ioctl(2) interface directly, it is closely entwined with libzfs, and not a public interface (not that libzfs is, either). It consists of a single file, which does some validation on the ioctl() parameters and then vectors the request to the appropriate place within ZFS.
84: 
85: |[[zfs_ioctl.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_ioctl.c]]|/dev/zfs ioctl() interface
86: |[[zfs.h>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/fs/zfs.h]]|Interfaces shared between kernel and userland
87: 
88: === DMU (Data Management Unit)
89: 
90: The DMU is responsible for presenting a transactional object model, built atop the flat address space presented by the SPA. Consumers interact with the DMU via objsets, objects, and transactions. An objset is a collection of objects, where each object is an arbitrary piece of storage from the SPA. Each transaction is a series of operations that must be committed to disk as a group; it is central to the on-disk consistency for ZFS.
91: 
92: |[[dmu.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dmu.c]]|Primary external DMU interfaces
93: |[[dmu_objset.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dmu_objset.c]]|Objset open/close/manipulate external interfaces
94: |[[dmu_object.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dmu_object.c]]|Object allocate/free interfaces
95: |[[txg.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/txg.c]]|Transaction model control threads
96: |[[dmu_tx.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dmu_tx.c]]|Transaction creation/manipulation interfaces
97: |[[dnode.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dnode.c]]|Open context object-level manipulation functions
98: |[[dnode_sync.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dnode_sync.c]]|Syncing context object-level manipulation functions
99: |[[dbuf.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dbuf.c]]|Buffer management functions
100: |[[dmu_zfetch.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dmu_zfetch.c]]|Data stream prefetch logic
101: |[[refcount.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/refcount.c]]|Generic reference counting interfaces
102: |[[dmu_send.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dmu_send.c]]|Send and receive functions for snapshots
103: 
104: === DSL (Dataset and Snapshot Layer)
105: 
106: The DSL aggregates DMU objsets into a hierarchical namespace, with inherited properties, as well as quota and reservation enforcement. It is also responsible for managing snapshots and clones of objsets.
107: 
108: For more information on how snapshots are implemented, see [[Matt’s blog entry>>http://blogs.sun.com/roller/page/ahrens?entry=is_it_magic]].
109: 
110: |[[dsl_dir.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dsl_dir.c]]|Namespace management functions
111: |[[dsl_dataset.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dsl_dataset.c]]|Snapshot/Rollback/Clone support interfaces
112: |[[dsl_pool.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dsl_pool.c]]|Pool-level support interfaces
113: |[[dsl_prop.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dsl_prop.c]]|Property manipulation functions
114: |[[unique.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/unique.c]]|Support functions for unique objset IDs
115: 
116: === ZAP (ZFS Attribute Processor)
117: 
118: The ZAP is built atop the DMU, and uses scalable hash algorithms to create arbitrary (name, object) associations within an objset. It is most commonly used to implement directories within the ZPL, but is also used extensively throughout the DSL, as well as a method of storing pool-wide properties. There are two very different ZAP algorithms, designed for different type of directories. The "micro zap" is used when the number of entries is relatively small and each entry is reasonably short. The "fat zap" is used for larger directories, or those with extremely long names.
119: 
120: |[[zap.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zap.c]]|Fat ZAP interfaces
121: |[[zap_leaf.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zap_leaf.c]]|Low-level support functions
122: |[[zap_micro.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zap_micro.c]]|Micro ZAP interfaces
123: 
124: === ZIL (ZFS Intent Log)
125: 
126: While ZFS provides always-consistent data on disk, it follows traditional filesystem semantics where the majority of data is not written to disk immediately; otherwise performance would be pathologically slow. But there are applications that require more stringent semantics where the data is guaranteed to be on disk by the time the read(2) or write(2) call returns. For those applications requiring this behavior (specified with O_DSYNC), the ZIL provides the necessary semantics using an efficient per-dataset transaction log that can be replayed in event of a crash.
127: 
128: For a more detailed look at the ZIL implementation, see Neil’s [[blog entry>>http://blogs.sun.com/roller/page/perrin?entry=the_lumberjack]].
129: 
130: |[[zil.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zil.c]]|Intent Log
131: 
132: === Traversal
133: 
134: Traversal provides a safe, efficient, restartable method of walking all data within a live pool. It forms the basis of resilvering and scrubbing. It walks all metadata looking for blocks modified within a certain period of time. Thanks to the copy-on-write nature of ZFS, this has the benefit of quickly excluding large subtrees that have not been touched during an outage period. It is fundamentally a SPA facility, but has intimate knowledge of some DMU structures in order to handle snapshots, clones, and certain other characteristics of the on-disk format.
135: 
136: |[[dmu_traverse.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/dmu_traverse.c]]|Traversal code
137: 
138: === ARC (Adaptive Replacement Cache)
139: 
140: ZFS uses a modified version of an Adaptive Replacement Cache to provide its primary cacheing needs. This cache is layered between the DMU and the SPA and so acts at the virtual block-level. This allows filesystems to share their cached data with their snapshots and clones.
141: 
142: |[[arc.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c]]|Adaptive Replacement Cache implementation
143: 
144: === Pool Configuration (SPA)
145: 
146: While the entire pool layer is often referred to as the SPA (Storage Pool Allocator), the configuration portion is really the public interface. It is responsible for gluing together the ZIO and vdev layers into a consistent pool object. It includes routines to create and destroy pools from their configuration information, as well as sync the data out to the vdevs on regular intervals.
147: 
148: |[[spa.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/spa.c]]|Routines for opening, importing, exporting, and destroying pools
149: |[[spa_misc.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/spa_misc.c]]|Miscellaneous SPA routines, including locking
150: |[[spa_config.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/spa_config.c]]|Parse and update pool configuration data
151: |[[spa_errlog.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/spa_errlog.c]]|Log of persistent pool-wide data errors.
152: |[[spa_history.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/spa_history.c]]|Persistent ring buffer of successful commands that modified the pool’s state.
153: |[[zfs_fm.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_fm.c]]|Routines to post ereports for FMA consumption.
154: 
155: === ZIO (ZFS I/O Pipeline)
156: 
157: The ZIO pipeline is where all data must pass when going to or from the disk. It is responsible for translation DVAs (Device Virtual Addresses) into logical locations on a vdev, as well as checksumming and compressing data as necessary. It is implemented as a multi-stage pipeline, with a bit mask to control which stage gets executed for each I/O. The pipeline itself is quite complex, but can be summed up by the following digram:
158: 
159: |=I/O types|=ZIO state|=Compression|=Checksum|=Gang Blocks |=DVA management|=Vdev I/O
160: |RWFCI|open|||||
161: |RWFCI|wait for
162: children ready|||||
163: |-W~---||write compress||||
164: |-W~---|||checksum generate|||
165: |-WFC-||||gang pipeline||
166: |-WFC-||||get gang header||
167: |-W~---||||rewrite gang
168: header||
169: |~--F~--||||free gang
170: members||
171: |~---C-||||claim gang
172: members||
173: |-W~---|||||DVA allocate|
174: |~--F~--|||||DVA free|
175: |~---C-|||||DVA claim|
176: |-W~---|||gang checksum
177: generate|||
178: |RWFCI|ready|||||
179: |RW~--I||||||I/O start
180: |RW~--I||||||I/O done
181: |RW~--I||||||I/O assess
182: |RWFCI|wait for
183: children done|||||
184: |R~----|||checksum verify|||
185: |R~----||||read gang
186: members||
187: |R~----||read decompress||||
188: |RWFCI|done|||||
189: 
190: ; I/O types
191: : Each phase of the I/O pipeline applies to a certain type of I/O. The letters stand for (R)ead, (W)rite, (F)ree, (C)laim, and (I)octl.
192: ; ZIO state
193: : These are internal states used to synchronize I/Os. For example, an I/O which child I/Os must wait for all children to be ready before allocating a BP, and must wait for all children to be done before returning.
194: ; Compression
195: : This phase applies any compression algorithms, if applicable.
196: ; Checksum
197: : This phase applies any checksum algorithms, if applicable.
198: ; Gang blocks
199: : When there is not enough contiguous space to write a complete block, the ZIO pipeline will break the I/O up into smaller ’gang blocks’ which can later be assembled transparently to appear as complete blocks.
200: ; DVA management
201: : Each I/O must be allocated a DVA (Device Virtual Address) to correspon to a particular portion of a vdev in the pool. These phases perform the necessary allocation of these addresses, using metaslabs and the space map.
202: ; Vdev I/O
203: : These phases are the once which actually issue I/O to the vdevs contained within the pool.
204: 
205: |[[zio.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zio.c]]|The main ZIO stages, including gang block translation
206: |[[zio_checksum.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zio_checksum.c]]|Generic checksum interface
207: |[[fletcher.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/fletcher.c]]|Fletcher2 and fletcher4 checksum algorithms
208: |[[sha256.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/sha256.c]]|SHA256 checksum algorithm
209: |[[zio_compress.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zio_compress.c]]|Generic compression interface
210: |[[lzjb.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/lzjb.c]]|LZJB compression algorithm
211: |[[uberblock.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/uberblock.c]]|Basic uberblock (root block) routines
212: |[[bplist.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/bplist.c]]|Keeps track of lists of block pointers
213: |[[metaslab.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/metaslab.c]]|The bulk of DVA translation
214: |[[space_map.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/space_map.c]]|Keeps track of free space, used during DVA translation
215: |[[szio_inject.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zio_inject.c]]|Framework for injecting persistent errors for data and devices
216: 
217: === VDEV (Virtual Devices)
218: 
219: The virtual device subsystem provides a unified method of arranging and accessing devices. Virtual devices form a tree, with a single root vdev and multiple interior (mirror and RAID-Z) and leaf (disk and file) vdevs. Each vdev is responsible for representing the available space, as well as laying out blocks on the physical disk.
220: 
221: |[[vdev.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev.c]]|Generic vdev routines
222: |[[vdev_disk.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_disk.c]]|Disk virtual device
223: |[[vdev_file.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_file.c]]|File virtual device
224: |[[vdev_mirror.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_mirror.c]]|N-Way mirrroring
225: |[[vdev_raidz.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_raidz.c]]|RAID-Z grouping (see [[Jeff’s blog>>http://blogs.sun.com/roller/page/bonwick?entry=raid_z]]).
226: |[[vdev_root.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_root.c]]|Toplevel pseudo vdev
227: |[[vdev_missing.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_missing.c]]|Special device for import
228: |[[vdev_label.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_label.c]]|Routines for reading and writing identifying labels
229: |[[vdev_cache.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_cache.c]]|Simple device-level caching for reads
230: |[[vdev_queue.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_queue.c]]|I/O Scheduling algorithm for vdevs
231: 
232: === LDI (Layered Driver Interface)
233: 
234: At the bottom of the stack, ZFS interacts with the underlying physical devices through LDI, the Layered Driver Interface, as well as the VFS interfaces (when dealing with files).
OpenSolaris

Top Menu

Wiki code for Source Tour

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group zfs Pages
