ZFS

This article is about the Sun Microsystems filesystem. For other uses, see ZFS (disambiguation).
ZFS
Developer(s) Oracle Corporation
Full name ZFS
Introduced November 2005 with OpenSolaris
Structures
Directory contents Extensible hash table
Limits
Max. volume size 256 zebibytes (278 bytes)[1]
Max. file size 16 exbibytes (264 bytes)
Max. number of files
  • Per directory: 248
  • Per file system: unlimited[1]
Max. filename length 255 ASCII characters (fewer for multibyte character encodings such as Unicode)
Features
Forks Yes (called "extended attributes", but they are full-fledged streams)
Attributes POSIX
File system permissions POSIX, NFSv4 ACLs
Transparent compression Yes
Transparent encryption Yes[2]
Data deduplication Yes
Copy-on-write Yes
Other
Supported operating systems Solaris, OpenSolaris, illumos distributions, OpenIndiana, FreeBSD, Mac OS X Server 10.5 (only read-only support), NetBSD, Linux via third-party kernel module[3] or ZFS-FUSE, OSv

ZFS is a combined file system and logical volume manager designed by Sun Microsystems. The features of ZFS include protection against data corruption, support for high storage capacities, efficient data compression, integration of the concepts of filesystem and volume management, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs.

The ZFS name is registered as a trademark of Oracle Corporation.[4] The ZFS name originally stood for "Zettabyte File System".[5] Originally, ZFS was proprietary, closed-source software developed internally by Sun as part of Solaris, with a team led by the CTO of Sun's storage business unit and Sun Fellow, Jeff Bonwick.[6][7] In 2005, the bulk of Solaris, including ZFS, was licensed as open-source software under the Common Development and Distribution License (CDDL), as the OpenSolaris project. ZFS became a standard feature of Solaris 10 in June 2006.

In 2010, Oracle stopped the releasing of source code for new OpenSolaris and ZFS development, effectively forking their closed-source development from the open-source branch. In response, OpenZFS was created as a new open-source development umbrella project,[8] aiming at bringing together individuals and companies that use the ZFS filesystem in an open-source manner.[9][10][11]

Overview and ZFS design goals

ZFS compared to most other file systems

Historically, the management of stored data has involved two aspects - the physical management of block devices such as hard drives and SDs, and devices such as RAID controllers that present a logical single device based upon multiple physical devices (often undertaken by a volume manager, array manager, or suitable device driver), and the management of files stored as logical units on these logical block devices (a file system).

Example: A RAID array of 2 hard drives and an SSD caching disk is controlled by Intel's RST system, part of the chipset and firmware built into a desktop computer. The user sees this as a single volume, containing an NTFS-formatted drive of their data, and NTFS is not necessarily aware of the manipulations that may be required (such as rebuilding the RAID array if a disk fails). The management of the individual devices and their presentation as a single device, is distinct from the management of the files held on that apparent device.

ZFS is unusual, because unlike most other storage systems, it unifies both of these roles and acts as both the volume manager and the file system. Therefore it has complete knowledge of both the physical disks and volumes (including their condition, status, their logical arrangement into volumes, and also of all the files stored on them). ZFS is designed to ensure (subject to suitable hardware) that data stored on disks cannot be lost due to physical error or misprocessing by the hardware or operating system, or bitrot events and data corruption which may happen over time, and its complete control of the storage system is used to ensure that every step, whether related to file management or disk management, is verified, confirmed, corrected if needed, and optimized, in a way that storage controller cards, and separate volume and file managers cannot achieve.

Summary of key differentiating features

Examples of features specific to ZFS which facilitate its objective include -

  • Designed for long term storage of data, and indefinitely scaled datastore sizes with zero data loss, and high configurability.
  • Hierarchical checksumming of all data and metadata, ensuring that the entire storage system can be verified on use, and confirmed to be correctly stored, or remedied if corrupt. Checksums are stored with a block's parent block, rather than with the block itself. This contrasts with many file systems where checksums (if held) are stored with the data so that if the data is lost or corrupt, the checksum is also likely to be lost or incorrect.
  • Can store a user-specified number of copies of data or metadata, or selected types of data, to improve the ability to recover from data corruption of important files and structures.
  • Automatic rollback of recent changes to the file system and data, in some circumstances, in the event of an error or inconsistency.
  • Automated and (usually) silent self-healing of data inconsistencies and write failure when detected, for all errors where the data is capable of reconstruction. Data can be reconstructed using all of the following: error detection and correction checksums stored in each block's parent block; multiple copies of data (including checksums) held on the disk; write intentions logged on the SLOG (ZIL) for writes that should have occurred but did not occur (after a power failure); parity data from RAID/RAIDZ disks and volumes; copies of data from mirrored disks and volumes.
  • Native handling of standard RAID levels and additional ZFS RAID layouts ("RAIDZ"). The RAIDZ levels stripe data across only the disks required, for efficiency (many RAID systems stripe indiscriminately across all devices), and checksumming allows rebuilding of inconsistent or corrupted data to be minimised to those blocks with defects;
  • Native handling of tiered storage and caching devices, which is usually a volume related task. Because it also understands the file system, it can use file-related knowledge to inform, integrate and optimize its tiered storage handling which a separate device cannot;
  • Native handling of snapshots and backup/replication which can be made efficient by integrating the volume and file handling. ZFS can routinely take snapshots several times an hour of the data system, efficiently and quickly. (Relevant tools are provided at a low level and require external scripts and software for utilization).
  • Native data compression and deduplication, although the latter is largely handled in RAM and is memory hungry.
  • Efficient rebuilding of RAID arrays - a RAID controller often has to rebuild an entire disk, but ZFS can combine disk and file knowledge to limit any rebuilding to data which is actually missing or corrupt, greatly speeding up rebuilding;
  • Ability to identify data that would have been found in a cache but has been discarded recently instead; this allows ZFS to reassess its caching decisions in light of later use and facilitates very high cache hit levels;
  • Alternative caching strategies can be used for data that would otherwise cause delays in data handling. For example, synchronous writes which are capable of slowing down the storage system can be converted to asynchronous writes by being written to a fast separate caching device, known as the SLOG (sometimes called the ZIL - ZFS Intent Log).
  • Can be used for high availability clusters and computing, although not fully designed for this use.

Inappropriately specified systems

Unlike many file systems, ZFS is intended to work in a specific way and towards specific ends. It expects or is designed with the assumption of a specific kind of hardware environment. If the system is not suitable for ZFS, then ZFS may underperform significantly. Common system design failures -

  • Inadequate RAM - ZFS may use a large amount of memory in many scenarios;
  • Inadequate disk free space - ZFS uses copy on write for data storage; its performance may suffer if the disk pool gets too close to full;
  • 'No efficient dedicated SLOG device, when synchronous writing is prominent - this is notably the case for NFS and ESXi; even SSD based systems may need a separate SLOG device for expected performance. The SLOG device is only used for writing apart from when recovering from a system error. It can often be small (for example, in FreeNAS, the SLOG device only needs to store the largest amount of data likely to be written in about 10 seconds (or the size of two 'transaction groups'), although it can be made larger to allow longer lifetime of the device). SLOG is therefore unusual in that its main criteria are pure write functionality, low latency, and loss protection - usually little else matters.
  • Lack of suitable caches, or misdesigned caches - for example, ZFS can cache read data in RAM ("ARC") or a separate device ("L2ARC"); in some cases adding extra ARC is needed, in other cases adding extra L2ARC is needed, and in some situations adding extra L2ARC can even degrade performance, by forcing RAM to be used for lookup data for the slower L2ARC, at the cost of less room for data in the ARC.
  • 'Use of hardware RAID cards, perhaps in the mistaken belief that these will 'help' ZFS. While routine for other filing systems, ZFS handles RAID natively, and is designed to work with a raw and unmodified low level view of storage devices, so it can fully use its functionality. A separate RAID card may leave ZFS less efficient and reliable. For example ZFS checksums all data, but most RAID cards will not do this as effectively, or for cached data. Separate cards can also mislead ZFS about the state of data, for example after a crash, or by mis-signalling exactly when data has safely been written, and in some cases this can lead to issues and data loss. Separate cards can also slow down the system, sometimes greatly, by adding latency to every data read/write operation, or by undertaking full rebuilds of damaged arrays where ZFS would have only needed to do minor repairs of a few seconds.

Features

Data integrity

One major feature that distinguishes ZFS from other file systems is that it is designed with a focus on data integrity by protecting the user's data on disk against silent data corruption caused by data degradation, current spikes, bugs in disk firmware, phantom writes (the previous write did not make it to disk), misdirected reads/writes (the disk accesses the wrong block), DMA parity errors between the array and server memory or from the driver (since the checksum validates data inside the array), driver errors (data winds up in the wrong buffer inside the kernel), accidental overwrites (such as swapping to a live file system), etc.

A 2012 research showed that neither any of the then-major and widespread filesystems (such as UFS, Ext,[12] XFS, JFS, or NTFS) nor hardware RAID (which has some issues with data integrity) provided sufficient protection against data corruption problems.[13][14][15][16] Initial research indicates that ZFS protects data better than earlier efforts.[17][18] It is also faster than UFS[19][20] and can be seen as its replacement.

ZFS data integrity

For ZFS, data integrity is achieved by using a Fletcher-based checksum or a SHA-256 hash throughout the file system tree.[21] Each block of data is checksummed and the checksum value is then saved in the pointer to that block—rather than at the actual block itself. Next, the block pointer is checksummed, with the value being saved at its pointer. This checksumming continues all the way up the file system's data hierarchy to the root node, which is also checksummed, thus creating a Merkle tree.[21] In-flight data corruption or phantom reads/writes (the data written/read checksums correctly but is actually wrong) are undetectable by most filesystems as they store the checksum with the data. ZFS stores the checksum of each block in its parent block pointer so the entire pool self-validates.[21]

When a block is accessed, regardless of whether it is data or meta-data, its checksum is calculated and compared with the stored checksum value of what it "should" be. If the checksums match, the data are passed up the programming stack to the process that asked for it; if the values do not match, then ZFS can heal the data if the storage pool provides data redundancy (such as with internal mirroring), assuming that the copy of data is undamaged and with matching checksums.[22] If the storage pool consists of a single disk, it is possible to provide such redundancy by specifying copies=2 (or copies=3), which means that data will be stored twice (or three times) on the disk, effectively halving (or, for copies=3, reducing to one third) the storage capacity of the disk.[23] If redundancy exists, ZFS will fetch a copy of the data (or recreate it via a RAID recovery mechanism), and recalculate the checksum—ideally resulting in the reproduction of the originally expected value. If the data passes this integrity check, the system can then update the faulty copy with known-good data so that redundancy can be restored.

RAID

ZFS and hardware RAID

If the disks are connected to a RAID controller, it is most efficient to configure it as a HBA in JBOD mode (i.e. turn off RAID function). If a hardware RAID card is used, ZFS always detects all data corruption but cannot always repair data corruption because the hardware RAID card will interfere. Therefore, the recommendation is to not use a hardware RAID card, or to flash a hardware RAID card into JBOD/IT mode. For ZFS to be able to guarantee data integrity, it needs to either have access to a RAID set (so all data is copied to at least two disks), or if one single disk is used, ZFS needs to enable redundancy (copies) which duplicates the data on the same logical drive. Using ZFS copies is a good feature to use on notebooks and desktop computers, since the disks are large and it at least provides some limited redundancy with just a single drive.

There are several reasons as to why it is better to rely solely on ZFS by using several independent disks and RAID-Z or mirroring.

When using hardware RAID, the controller usually adds controller-dependent data to the drives which prevents software RAID from accessing the user data. While it is possible to read the data with a compatible hardware RAID controller, this inconveniences consumers as a compatible controller usually isn't readily available. Using the JBOD/RAID-Z combination, any disk controller can be used to resume operation after a controller failure.

Note that hardware RAID configured as JBOD may still detach drives that do not respond in time (as has been seen with many energy-efficient consumer-grade hard drives), and as such, may require TLER/CCTL/ERC-enabled drives to prevent drive dropouts.[24]

Software RAID using ZFS

ZFS offers software RAID through its RAID-Z and mirroring organization schemes.

RAID-Z is a data/parity distribution scheme like RAID-5, but uses dynamic stripe width: every block is its own RAID stripe, regardless of blocksize, resulting in every RAID-Z write being a full-stripe write. This, when combined with the copy-on-write transactional semantics of ZFS, eliminates the write hole error. RAID-Z is also faster than traditional RAID 5 because it does not need to perform the usual read-modify-write sequence.[25]

As all stripes are of different sizes, RAID-Z reconstruction has to traverse the filesystem metadata to determine the actual RAID-Z geometry. This would be impossible if the filesystem and the RAID array were separate products, whereas it becomes feasible when there is an integrated view of the logical and physical structure of the data. Going through the metadata means that ZFS can validate every block against its 256-bit checksum as it goes, whereas traditional RAID products usually cannot do this.[25]

In addition to handling whole-disk failures, RAID-Z can also detect and correct silent data corruption, offering "self-healing data": when reading a RAID-Z block, ZFS compares it against its checksum, and if the data disks did not return the right answer, ZFS reads the parity and then figures out which disk returned bad data. Then, it repairs the damaged data and returns good data to the requestor.[25]

RAID-Z does not require any special hardware: it does not need NVRAM for reliability, and it does not need write buffering for good performance. With RAID-Z, ZFS provides fast, reliable storage using cheap, commodity disks.[25]

There are three different RAID-Z modes: RAID-Z1 (similar to RAID 5, allows one disk to fail), RAID-Z2 (similar to RAID 6, allows two disks to fail), and RAID-Z3 (allows three disks to fail). The need for RAID-Z3 arose recently because RAID configurations with future disks (say, 6–10 TB) may take a long time to repair, the worst case being weeks. During those weeks, the rest of the disks in the RAID are stressed more because of the additional intensive repair process and might subsequently fail, too. By using RAID-Z3, the risk involved with disk replacement is reduced.[26]

Mirroring, the other ZFS RAID option, is essentially the same as RAID 1, allowing any number of disks to be mirrored.[27]

Resilvering and scrub

ZFS has no fsck repair tool equivalent, common on Unix filesystems, which does file system validation and file system repair.[28] Instead, ZFS has a repair tool called "scrub" which examines and repairs silent corruption and other problems. Some differences are:

The official recommendation from Sun/Oracle is to scrub enterprise-level disks once a month, and cheaper commodity disks once a week.[29][30]

Capacity

ZFS is a 128-bit file system,[31][32] so it can address 1.84 × 1019 times more data than 64-bit systems such as Btrfs. The limitations of ZFS are designed to be so large that they should never be encountered in practice. For instance, fully populating a single zpool with 2128 bits of data would require 1024 3 TB hard disk drives.[33]

Some theoretical limits in ZFS are:

Encryption

With Oracle Solaris, the encryption capability in ZFS[35] is embedded into the I/O pipeline. During writes, a block may be compressed, encrypted, checksummed and then deduplicated, in that order. The policy for encryption is set at the dataset level when datasets (file systems or ZVOLs) are created. The wrapping keys provided by the user/administrator can be changed at any time without taking the file system offline. The default behaviour is for the wrapping key to be inherited by any child data sets. The data encryption keys are randomly generated at dataset creation time. Only descendant datasets (snapshots and clones) share data encryption keys.[36] A command to switch to a new data encryption key for the clone or at any time is provided—this does not re-encrypt already existing data, instead utilising an encrypted master-key mechanism.

Other features

Storage pools

Unlike traditional filesystems which reside on single devices and thus require a volume manager to use more than one device, ZFS filesystems are built on top of virtual storage pools called zpools. A zpool is constructed of virtual devices (vdevs), themselves constructed of block devices: files, hard drive partitions, or entire drives, with the latter being the recommended usage.[37] Block devices within a vdev may be configured in different ways, depending on needs and space available: non-redundantly (similar to RAID 0), as a mirror (RAID 1) of two or more devices, as a RAID-Z group of three or more devices, or as a RAID-Z2 (similar to RAID-6) group of four or more devices.[38] In July 2009, triple-parity RAID-Z3 was added to OpenSolaris.[39][40] RAID-Z is a data-protection technology featured by ZFS in order to reduce the block overhead in mirroring.[41]

Thus, a zpool (ZFS storage pool) is vaguely similar to a computer's RAM. The total RAM pool capacity depends on the number of RAM memory sticks and the size of each stick. Likewise, a zpool consists of one or more vdevs. Each vdev can be viewed as a group of hard disks (or partitions, or files, etc.). Each vdev should have redundancy, otherwise if a vdev is lost, then the whole zpool is lost. Thus, each vdev should be configured as RAID-Z1, RAID-Z2, mirror, etc. It is not possible to change the number of drives in an existing vdev (Block Pointer Rewrite will allow this, and also allow defragmentation), but it is always possible to increase storage capacity by adding a new vdev to a zpool. It is possible to swap a drive to a larger drive and resilver (repair) the zpool. If this procedure is repeated for every disk in a vdev, then the zpool will grow in capacity when the last drive is resilvered. A vdev will have the same base capacity as the smallest drive in the group. For instance, a vdev consisting of three 500 GB and one 700 GB drive, will have a capacity of 4×500 GB.

In addition, pools can have hot spares to compensate for failing disks. When mirroring, block devices can be grouped according to physical chassis, so that the filesystem can continue in the case of the failure of an entire chassis.

Storage pool composition is not limited to similar devices, but can consist of ad-hoc, heterogeneous collections of devices, which ZFS seamlessly pools together, subsequently doling out space to diverse filesystems as needed. Arbitrary storage device types can be added to existing pools to expand their size.[42]

The storage capacity of all vdevs is available to all of the file system instances in the zpool. A quota can be set to limit the amount of space a file system instance can occupy, and a reservation can be set to guarantee that space will be available to a file system instance.

ZFS cache: ARC (L1), L2ARC, ZIL

ZFS uses different layers of disk cache to speed up read and write operations. Ideally, all data should be stored in RAM, but that is too expensive. Therefore, data is automatically cached in a hierarchy to optimize performance vs cost.[43] Frequently accessed data is stored in RAM, and less frequently accessed data can be stored on slower media, such as SSDs. Data that is not often accessed is not cached and left on the slow hard drives. If old data is suddenly read a lot, ZFS will automatically move it to SSDs or to RAM.

The first level of disk cache is RAM, which uses a variant of the ARC algorithm. It is similar to a level 1 CPU cache. RAM will always be used for caching, thus this level is always present. There are claims that ZFS servers must have huge amounts of RAM, but that is not true. It is a misinterpretation of the desire to have large ARC disk caches. The ARC is very clever and efficient, which means disks will often not be touched at all, provided the ARC size is sufficiently large. In the worst case, if the RAM size is very small (say, 1 GB), there will hardly be any ARC at all; in this case, ZFS always needs to reach for the disks. This means read performance degrades to disk speed.

The second level of disk cache are SSDs. This level is optional, and is easy to add or remove during live usage, as there is no need to shut down the zpool. There are two different caches; one cache for reads, and one for writes.

Copy-on-write transactional model

ZFS uses a copy-on-write transactional object model. All block pointers within the filesystem contain a 256-bit checksum or 256-bit hash (currently a choice between Fletcher-2, Fletcher-4, or SHA-256)[45] of the target block, which is verified when the block is read. Blocks containing active data are never overwritten in place; instead, a new block is allocated, modified data is written to it, then any metadata blocks referencing it are similarly read, reallocated, and written. To reduce the overhead of this process, multiple updates are grouped into transaction groups, and ZIL (intent log) write cache is used when synchronous write semantics are required. The blocks are arranged in a tree, as are their checksums (see Merkle signature scheme).

Snapshots and clones

An advantage of copy-on-write is that, when ZFS writes new data, the blocks containing the old data can be retained, allowing a snapshot version of the file system to be maintained. ZFS snapshots are created very quickly, since all the data composing the snapshot is already stored. They are also space efficient, since any unchanged data is shared among the file system and its snapshots.

Writeable snapshots ("clones") can also be created, resulting in two independent file systems that share a set of blocks. As changes are made to any of the clone file systems, new data blocks are created to reflect those changes, but any unchanged blocks continue to be shared, no matter how many clones exist. This is an implementation of the Copy-on-write principle.

Sending and receiving snapshots

ZFS file systems can be moved to other pools, also on remote hosts over the network, as the send command creates a stream representation of the file system's state. This stream can either describe complete contents of the file system at a given snapshot, or it can be a delta between snapshots. Computing the delta stream is very efficient, and its size depends on the number of blocks changed between the snapshots. This provides an efficient strategy, e.g. for synchronizing offsite backups or high availability mirrors of a pool.

Dynamic striping

Dynamic striping across all devices to maximize throughput means that as additional devices are added to the zpool, the stripe width automatically expands to include them; thus, all disks in a pool are used, which balances the write load across them.

Variable block sizes

ZFS uses variable-sized blocks, with 128 KB as the default size. Available features allow the administrator to tune the maximum block size which is used, as certain workloads do not perform well with large blocks. If data compression is enabled, variable block sizes are used. If a block can be compressed to fit into a smaller block size, the smaller size is used on the disk to use less storage and improve IO throughput (though at the cost of increased CPU use for the compression and decompression operations).[46]

Lightweight filesystem creation

In ZFS, filesystem manipulation within a storage pool is easier than volume manipulation within a traditional filesystem; the time and effort required to create or expand a ZFS filesystem is closer to that of making a new directory than it is to volume manipulation in some other systems.

Cache management

ZFS also uses the Adaptive Replacement Cache (ARC), a new method for read cache management, instead of the traditional Solaris virtual memory page cache. For write caching, ZFS employs the ZFS Intent Log (ZIL). ZFS makes allowances for both of these methods to incorporate separate virtual devices to improve the total IOPS. For read operations it is the "cache" vdev and for write operations it is the "log" vdev.[47]

Adaptive endianness

Pools and their associated ZFS file systems can be moved between different platform architectures, including systems implementing different byte orders. The ZFS block pointer format stores filesystem metadata in an endian-adaptive way; individual metadata blocks are written with the native byte order of the system writing the block. When reading, if the stored endianness does not match the endianness of the system, the metadata is byte-swapped in memory.

This does not affect the stored data; as is usual in POSIX systems, files appear to applications as simple arrays of bytes, so applications creating and reading data remain responsible for doing so in a way independent of the underlying system's endianness.

Deduplication

Data deduplication capabilities were added to the ZFS source repository at the end of October 2009,[48] and relevant OpenSolaris ZFS development packages have been available since December 3, 2009 (build 128).

Effective use of deduplication may require large RAM capacity; recommendations range between 1 and 5 GB of RAM for every TB of storage.[49][50][51] Insufficient physical memory or lack of ZFS cache can result in virtual memory thrashing when using deduplication, which can either lower performance or result in complete memory starvation. Solid-state drives (SSDs) can be used to cache deduplication tables, thereby speeding up deduplication performance.

Other storage vendors use modified versions of ZFS to achieve very high data compression ratios. Two examples in 2012 were GreenBytes[52] and Tegile.[53] In May 2014, Oracle bought GreenBytes for its ZFS deduplication and replication technology.[54]

Additional capabilities

Limitations

Limitations in preventing data corruption

A 2010 paper examining the ability of file systems to detect and prevent data corruption, observed that ZFS itself is effective in detecting and correcting data errors on storage devices, but that it assumes data in RAM is "safe", and not prone to error. Thus when ZFS caches pages, or stores copies of metadata, in RAM, or holds data in its "dirty" cache for writing to disk, no test is made whether the checksums still match the data at the point of use. Much of this risk can be mitigated by use of ECC RAM but the authors considered that error detection related to the page cache and heap would allow ZFS to handle certain classes of error more robustly.[61]

The authors of a study entirely dedicated to ZFS data integrity point out that "[...] a single bit flip in memory causes a small but non-negligible percentage of runs to experience a failure", with the probability of committing bad data to disk varying from 0% to 3.6% (according to the workload). Please note that all software (including other file systems) is vulnerable to faulty hardware (CPUs, RAM, PSUs, etc) not only ZFS.

It should be noted that ZFS has an option that makes it more robust when it comes to corrupt RAM (but also has an impact on performance). The option is enabled using the "ZFS_DEBUG_MODIFY flag (zfs_flags=0x10)" as explained by Matt Ahrens, who is one of the main architects of ZFS. This will enable a second checksum of in-memory data before committing changes to disk. [62] With the option tuned on, the chanced of corrupt RAM causing a bad commit are greatly reduced. Nonetheless, if a checksum collision happens (whatever the reason) bad data could still be written to disk.

Long story short, and to use the words of Ahrens himself: "There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem [...] (but) if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS".

Limitations specific to ZFS

Platforms

Solaris

Solaris 10 update 2 and later

ZFS is part of Sun's own Solaris operating system and is thus available on both SPARC and x86-based systems.

Solaris 11

After Oracle's Solaris 11 Express release, the OS/Net consolidation (the main OS code) was made proprietary and closed-source,[69] and further ZFS upgrades and implementations inside Solaris (such as encryption) are not compatible with other non-proprietary implementations which use previous versions of ZFS.

When creating a new ZFS pool, to retain the ability to use access the pool from other non-proprietary Solaris-based distributions, it is recommended to upgrade to Solaris 11 Express from OpenSolaris (snv_134b), and thereby stay at ZFS version 28.

OpenSolaris

OpenSolaris 2008.05, 2008.11 and 2009.06 use ZFS as their default filesystem. There are over a dozen 3rd-party distributions, of which nearly a dozen are mentioned here. (OpenIndiana and illumos are two new distributions not included on the OpenSolaris distribution reference page.)

OpenIndiana

OpenIndiana uses OpenZFS with feature flags as implemented in Illumos. ZFS version 28 used up to version 151a3.[70]

By upgrading from OpenSolaris snv_134 to both OpenIndiana and Solaris 11 Express, one also has the ability to upgrade and separately boot Solaris 11 Express on the same ZFS pool, but one should not install Solaris 11 Express first because of ZFS incompatibilities introduced by Oracle past ZFS version 28.[71]

BSD

macOS

OpenZFS on OSX (abbreviated to O3X) is an implementation of ZFS for MacOS.[72] O3X is under active development, with close relation to ZFS on Linux and illumos' ZFS implementation, while maintaining feature flag compatibility with ZFS on Linux. O3X implements zpool version 5000, and includes the Solaris Porting Layer (SPL) originally authored for MacZFS, which has been further enhanced to include a memory management layer based on the illumos kmem and vmem allocators. O3X is fully featured, supporting LZ4 compression, deduplication, ARC, L2ARC, and SLOG.

MacZFS is free software providing support for ZFS on OS X. The stable legacy branch provides up to ZFS pool version 8 and ZFS filesystem version 2. The development branch, based on ZFS on Linux and OpenZFS, provides updated ZFS functionality, such as up to ZFS zpool version 5000 and feature flags.[73][74]

A proprietary implementation of ZFS (Zevo) was available at no cost from GreenBytes, Inc., implementing up to ZFS file system version 5 and ZFS pool version 28.[75] Zevo offered a limited ZFS feature set, pending further commercial development; it was sold to Oracle in 2014, with unknown future plans.

DragonFlyBSD

Edward O'Callaghan started the initial port of ZFS to DragonFlyBSD.[76]

NetBSD

The NetBSD ZFS port was started as a part of the 2007 Google Summer of Code and in August 2009, the code was merged into NetBSD's source tree.[77]

FreeBSD

Paweł Jakub Dawidek ported ZFS to FreeBSD, and it has been part of FreeBSD since version 7.0.[78] This includes zfsboot, which allows booting FreeBSD directly from a ZFS volume.[79][80]

FreeBSD's ZFS implementation is fully functional; the only missing features are kernel CIFS server and iSCSI, but the latter can be added using externally available packages.[81] Samba can be used to provide a userspace CIFS server.

FreeBSD 7-STABLE (where updates to the series of versions 7.x are committed to) uses zpool version 6.

FreeBSD 8 includes a much-updated implementation of ZFS, and zpool version 13 is supported.[82] zpool version 14 support was added to the 8-STABLE branch on January 11, 2010,[83] and is included in FreeBSD release 8.1. zpool version 15 is supported in release 8.2.[84] The 8-STABLE branch gained support for zpool version v28 and zfs version 5 in early June 2011.[85] These changes were released mid-April 2012 with FreeBSD 8.3.[86]

FreeBSD 9.0-RELEASE uses ZFS Pool version 28.[87][88]

FreeBSD 9.2-RELEASE is the first FreeBSD version to use the new "feature flags" based implementation thus Pool version 5000.[89]

MidnightBSD

MidnightBSD, a desktop operating system derived from FreeBSD, supports ZFS storage pool version 6 as of 0.3-RELEASE. This was derived from code included in FreeBSD 7.0-RELEASE. An update to storage pool 28 is in progress in 0.4-CURRENT and based on 9-STABLE sources around FreeBSD 9.1-RELEASE code.

TrueOS (PC-BSD)

TrueOS (formerly known as PC-BSD) is a desktop version of FreeBSD, which inherits FreeBSD's ZFS support, similarly to FreeNAS. It also allows installation with disk encryption using geli. Its graphical installer can handle even / (root) on ZFS and RAID-Z pool and Gnome installs right from the start in an easy convenient way (GUI).

FreeNAS

FreeNAS, an embedded open source network-attached storage (NAS) distribution based on FreeBSD, has the same ZFS support as FreeBSD and PC-BSD.

ZFS Guru

ZFS Guru, an embedded open source network-attached storage (NAS) distribution based on FreeBSD, under active development.

NAS4Free

NAS4Free, an embedded open source network-attached storage (NAS) distribution based on FreeBSD, has the same ZFS support as FreeBSD, ZFS storage pool version 5000. This project is a continuation of FreeNAS 7 series project.[90]

Debian GNU/kFreeBSD

Being based on the FreeBSD kernel, Debian GNU/kFreeBSD has ZFS support from the kernel. However, additional userland tools are required,[91] while it is possible to have ZFS as root or /boot file system[92] in which case required GRUB configuration is performed by the Debian installer since the Wheezy release.[93]

As of 31 January 2013, the ZPool version available is 14 for the Squeeze release, and 28 for the Wheezy-9 release.[94]

Linux

Although the ZFS filesystem supports Linux-based operating systems, difficulties arise for Linux distribution maintainers wishing to provide native support for ZFS in their products due to potential legal incompatibilities between the CDDL license used by the ZFS code, and the GPL license used by the Linux kernel. To enable ZFS support within Linux, a loadable kernel module containing the CDDL-licensed ZFS code must be compiled and loaded into the kernel. According to the Free Software Foundation, the wording of the GPL license legally prohibits redistribution of the resulting product as a derivative work,[95][96] though this viewpoint has caused some controversy.[97][98]

ZFS on FUSE

One potential workaround to licensing incompatibility was trialed in 2006, with an experimental port of the ZFS code to Linux's FUSE system. The filesystem ran entirely in userspace instead of being integrated into the Linux kernel, and was therefore not considered a derivative work of the kernel. This approach was functional, but suffered from significant performance penalties when compared with integrating the filesystem as a native kernel module running in kernel space.[99] As of 2016, the ZFS on FUSE project appears to be defunct.

Native ZFS on Linux

A native port of ZFS for Linux produced by the Lawrence Livermore National Laboratory (LLNL) was released in March 2013,[100][101] following these key events:[102]

As of August 2014, ZFS on Linux uses the OpenZFS pool version number 5000, which indicates that the features it supports are defined via feature flags. This pool version is an unchanging number that is expected to never conflict with version numbers given by Oracle.[103]

KQ InfoTech

Another native port for Linux was developed by KQ InfoTech in 2010.[104][105] This port used the zvol implementation from the Lawrence Livermore National Laboratory as a starting point. A release supporting zpool v28 was announced in January 2011.[106] In April 2011, KQ Infotech was acquired by sTec, Inc., and their work on ZFS ceased.[107] Source code of this port can be found on GitHub.[108]

The work of KQ InfoTech was ultimately integrated into the LLNL's native port of ZFS for Linux.[107]

Source code distribution

While the license incompatibility may arise with the distribution of compiled binaries containing ZFS code, it is generally agreed that distribution of the source code itself is not affected by this. In Gentoo, configuring a ZFS root filesystem is well documented and the required packages can be installed from its package repository.[109] Slackware also provides documentation on supporting ZFS, both as a kernel module[110] and when built into the kernel.[111]

Ubuntu integration

The question of the CDDL license's compatibility with the GPL license resurfaced in 2015, when the Linux distribution Ubuntu announced that it intended to make precompiled OpenZFS binary kernel modules available to end-users directly from the distribution's official package repositories.[112] In 2016, Ubuntu announced that a legal review resulted in the conclusion that providing support for ZFS via a binary kernel module was not in violation of the provisions of the GPL license.[113] Others followed Ubuntu's conclusion,[114][115] while the FSF and SFC reiterated their opposing view.[116][117]

Ubuntu 16.04 LTS ("Xenial Xerus"), released on April 21, 2016, allows the user to install the OpenZFS binary packages directly from the Ubuntu software repositories.[118][119][120][121] As of September 2016, no legal challenge has been brought against Canonical or Ubuntu regarding the distribution of these packages.

List of operating systems supporting ZFS

List of Operating Systems, distributions and add-ons that support ZFS, the zpool version it supports, and the Solaris build they are based on (if any):

OS Zpool version Sun/Oracle Build # Comments
Oracle Solaris 11.3 37 0.5.11-0.175.3.1.0.5.0
Oracle Solaris 11.2 35 0.5.11-0.175.2.0.0.42.0
Oracle Solaris 11 2011.11 34 b175
Oracle Solaris Express 11 2010.11 31 b151a licensed for testing only
OpenSolaris 2009.06 14 b111b
OpenSolaris (last dev) 22 b134
OpenIndiana 5000 b147 OpenIndiana creates a name clash with naming their code b151a
Nexenta Core 3.0.1 26 b134+ GNU userland
NexentaStor Community 3.0.1 26 b134+ up to 18 TB, web admin
NexentaStor Community 3.1.0 28 b134+ GNU userland
NexentaStor Community 4.0 5000 b134+ up to 18 TB, web admin
NexentaStor Enterprise 28 b134 + not free, web admin
GNU/kFreeBSD "Squeeze" (as of 1/31/2013) 14 Requires package "zfsutils"
GNU/kFreeBSD "Wheezy-9" (as of 2/21/2013) 28 Requires package "zfsutils"
FreeBSD 5000
zfs-fuse 0.7.2 23 suffered from performance issues; now defunct
ZFS on Linux 0.6.5.8 5000 0.6.0 release candidate has POSIX layer
KQ Infotech's ZFS on Linux 28 now defunct; code integrated into LLNL-supported ZFS on Linux
BeleniX 0.8b1 14 b111
Schillix 0.7.2 28 b147
StormOS "hail" based on Nexenta
Jaris Japanese
MilaX 0.5 20 b128a small size
FreeNAS 8.0.2 / 8.2 15
FreeNAS 8.3.0 28 based on FreeBSD 8.3
FreeNAS 9.1.0 5000 based on FreeBSD 9.1
NAS4Free 10.2.0.2/10.3.0.3 5000 based on FreeBSD 10.2/10.3
Korona 4.5.0 22 b134 KDE
EON NAS (v0.6) 22 b130 embedded NAS
EON NAS (v1.0beta) 28 b151a embedded NAS
napp-it 28/5000 Illumos/ Solaris Storage appliance with Web-UI for OpenIndiana (Hipster), OmniOS, Solaris 11 or Linux (ZFS management)
OmniOS 28/5000 illumos-omnios branch minimal storage server distribution based on Illumos
SmartOS 28/5000 Illumos b151+ minimal live distribution based on Illumos (boots from USB/CD) suited for cloud and hypervisor use (KVM)
OS X 10.5, 10.6, 10.7, 10.8, and 10.9 5000 MacZFS
OS X 10.6, 10.7 and 10.8 28 ZEVO
NetBSD 22
MidnightBSD 6
Ubuntu 16.04 LTS 5000 offers native support via installable binary module
ZFSGuru 10.1.100 5000

History

ZFS was designed and implemented by a team at Sun led by Jeff Bonwick, Bill Moore[122] and Matthew Ahrens. It was announced on September 14, 2004,[123] but development started in 2001.[124] Source code for ZFS was integrated into the main trunk of Solaris development on October 31, 2005[32] and released as part of build 27 of OpenSolaris on November 16, 2005. Sun announced that ZFS was included in the 6/06 update to Solaris 10 in June 2006, one year after the opening of the OpenSolaris community.[125]

The name originally stood for "Zettabyte File System",[5] but today does not stand for anything.[126] A ZFS file system can store up to 256 zebibytes (ZiB).

In September 2007, NetApp sued Sun claiming that ZFS infringed some of NetApp's patents on Write Anywhere File Layout. Sun counter-sued in October the same year claiming the opposite. The lawsuits were ended in 2010 with an undisclosed settlement.[127]

Open source implementations

The following is a list of events in the development of open-source ZFS implementations:[102][128]

Use in commercial products

Detailed release history

With ZFS in Oracle Solaris: as new features are introduced, the version numbers of the pool and file system are incremented to designate the format and features available. Features that are available in specific file system versions require a specific pool version.[134][135]

Distributed development of OpenZFS involves feature flags[73] and pool version 5000, an unchanging number that is expected to never conflict with version numbers given by Oracle. Legacy version numbers still exist for pool versions 1–28, implied by the version 5000.[136] Illumos uses pool version 5000 for this purpose.[137][138] Future on-disk format changes are enabled / disabled independently via feature flags.

Legend:
Old release
Latest FOSS stable release
Latest Proprietary stable release
Latest Proprietary beta release
ZFS Filesystem Version Number Release date Significant changes
1 OpenSolaris Nevada[139] build 36 First release
2 OpenSolaris Nevada b69 Enhanced directory entries. In particular, directory entries now store the object type. For example, file, directory, named pipe, and so on, in addition to the object number.
3 OpenSolaris Nevada b77 Support for sharing ZFS file systems over SMB. Case insensitivity support. System attribute support. Integrated anti-virus support.
4 OpenSolaris Nevada b114 Properties: userquota, groupquota, userused and groupused
5 OpenSolaris Nevada b137 System attributes; symlinks now their own object type
6 Solaris 11.1 Multilevel file system support
ZFS Pool Version Number Release date Significant changes
1 OpenSolaris Nevada[139] b36 First release
2 OpenSolaris Nevada b38 Ditto Blocks
3 OpenSolaris Nevada b42 Hot spares, double-parity RAID-Z (raidz2), improved RAID-Z accounting
4 OpenSolaris Nevada b62 zpool history
5 OpenSolaris Nevada b62 gzip compression for ZFS datasets
6 OpenSolaris Nevada b62 "bootfs" pool property
7 OpenSolaris Nevada b68 ZIL: adds the capability to specify a separate Intent Log device or devices
8 OpenSolaris Nevada b69 ability to delegate zfs(1M) administrative tasks to ordinary users
9 OpenSolaris Nevada b77 CIFS server support, dataset quotas
10 OpenSolaris Nevada b77 Devices can be added to a storage pool as "cache devices"
11 OpenSolaris Nevada b94 Improved zpool scrub / resilver performance
12 OpenSolaris Nevada b96 Snapshot properties
13 OpenSolaris Nevada b98 Properties: usedbysnapshots, usedbychildren, usedbyrefreservation, and usedbydataset
14 OpenSolaris Nevada b103 passthrough-x aclinherit property support
15 OpenSolaris Nevada b114 Properties: userquota, groupquota, usuerused and groupused; also required FS v4
16 OpenSolaris Nevada b116 STMF property support
17 OpenSolaris Nevada b120 triple-parity RAID-Z
18 OpenSolaris Nevada b121 ZFS snapshot holds
19 OpenSolaris Nevada b125 ZFS log device removal
20 OpenSolaris Nevada b128 zle compression algorithm that is needed to support the ZFS deduplication properties in ZFS pool version 21, which were released concurrently
21 OpenSolaris Nevada b128 Deduplication
22 OpenSolaris Nevada b128 zfs receive properties
23 OpenSolaris Nevada b135 slim ZIL
24 OpenSolaris Nevada b137 System attributes. Symlinks now their own object type. Also requires FS v5.
25 OpenSolaris Nevada b140 Improved pool scrubbing and resilvering statistics
26 OpenSolaris Nevada b141 Improved snapshot deletion performance
27 OpenSolaris Nevada b145 Improved snapshot creation performance (particularly recursive snapshots)
28 OpenSolaris Nevada b147 Multiple virtual device replacements
29 Solaris Nevada b148 RAID-Z/mirror hybrid allocator
30 Solaris Nevada b149 ZFS encryption
31 Solaris Nevada b150 Improved 'zfs list' performance
32 Solaris Nevada b151 One MB block support
33 Solaris Nevada b163 Improved share support
34 Solaris 11.1 (0.5.11-0.175.1.0.0.24.2) Sharing with inheritance
35 Solaris 11.2 (0.5.11-0.175.2.0.0.42.0) Sequential resilver
36 Solaris 11.3 Efficient log block allocation
37 Solaris 11.3 LZ4 compression
5000 OpenZFS Unchanging pool version to signify that the pool indicates new features after pool version 28 using ZFS feature flags rather than by incrementing the pool version

Note: The Solaris version under development by Sun since the release of Solaris 10 in 2005 was codenamed 'Nevada', and was derived from what was the OpenSolaris codebase. 'Solaris Nevada' is the codename for the next-generation Solaris OS to eventually succeed Solaris 10 and this new code was then pulled successively into new OpenSolaris 'Nevada' snapshot builds.[139] OpenSolaris is now discontinued and OpenIndiana forked from it.[140][141] A final build (b134) of OpenSolaris was published by Oracle (2010-Nov-12) as an upgrade path to Solaris 11 Express.

OS X

The first indication of Apple Inc.'s interest in ZFS was an April 2006 post on the opensolaris.org zfs-discuss mailing list where an Apple employee mentioned being interested in porting ZFS to their OS X operating system.[142] In the release version of Mac OS X 10.5, ZFS was available in read-only mode from the command line, which lacks the possibility to create zpools or write to them.[143] Before the 10.5 release, Apple released the "ZFS Beta Seed v1.1", which allowed read-write access and the creation of zpools,;[144] however, the installer for the "ZFS Beta Seed v1.1" has been reported to only work on version 10.5.0, and has not been updated for version 10.5.1 and above.[145] In August 2007, Apple opened a ZFS project on their Mac OS Forge web site. On that site, Apple provided the source code and binaries of their port of ZFS which includes read-write access, but there was no installer available[146] until a third-party developer created one.[147] In October 2009, Apple announced a shutdown of the ZFS project on Mac OS Forge. That is to say that their own hosting and involvement in ZFS was summarily discontinued. No explanation was given, just the following statement: "The ZFS project has been discontinued. The mailing list and repository will also be removed shortly." Apple would eventually release the legally required, CDDL-derived, portion of the source code of their final public beta of ZFS, code named "10a286". Complete ZFS support was once advertised as a feature of Snow Leopard Server (Mac OS X Server 10.6).[148] However, by the time the operating system was released, all references to this feature had been silently removed from its features page.[149] Apple has not commented regarding the omission.

Apple's "10a286" source code release, and versions of the previously released source and binaries, have been preserved and new development has been adopted by a group of enthusiasts.[150][151] The MacZFS (now github) project acted quickly to mirror the public archives of Apple's project before the materials would have disappeared from the internet, and then to resume its development elsewhere. The MacZFS community has curated and matured the project, supporting ZFS for all Mac OS releases since 10.5. The project has an active mailing list. As of July 2012, MacZFS implements zpool version 8 and ZFS version 2, from the October 2008 release of Solaris. Additional historical information and commentary can be found on the MacZFS web site and (broken) Frequently Asked Questions page.

The 17th September 2013 launch of OpenZFS included ZFS-OSX, which will become a new version of MacZFS, as the distribution for Darwin.[152]

See also

References

  1. 1 2 "What Is ZFS?". Oracle Solaris ZFS Administration Guide. Oracle. Retrieved 29 December 2015.
  2. 1 2 "What's new in Solaris 11 Express 2010.11" (PDF). Oracle. Retrieved November 17, 2010.
  3. "1.1 What about the licensing issue?". Retrieved November 18, 2010.
  4. "Status Information for Serial Number 85901629 (ZFS)". United States Patent and Trademark Office. Retrieved October 21, 2013.
  5. 1 2 "ZFS FAQ at OpenSolaris.org". Sun Microsystems. Archived from the original on May 15, 2011. Retrieved May 18, 2011. The largest SI prefix we liked was 'zetta' ('yotta' was out of the question)
  6. "The Birth of ZFS". OpenZFS. Retrieved October 21, 2015.
  7. "Sun's ZFS Creator to Quit Oracle and Join Startup". eWeek. Retrieved September 29, 2010.
  8. /History on open-zfs.org "OpenZFS is the truly open source successor to the ZFS project [...] Effects of the fork (2010 to date)"
  9. Sean Michael Kerner (2013-09-18). "LinuxCon: OpenZFS moves Open Source Storage Forward". infostor.com. Retrieved 2013-10-09.
  10. "The OpenZFS project launches". LWN.net. 2013-09-17. Retrieved 2013-10-01.
  11. "OpenZFS – Communities co-operating on ZFS code and features". freebsdnews.net. 2013-09-23. Retrieved 2014-03-14.
  12. The Extended file system (Ext) has metadata structure copied from UFS. "Rémy Card (Interview, April 1998)". April Association. April 19, 1999. Retrieved 2012-02-08. (In French)
  13. Vijayan Prabhakaran (2006). "IRON FILE SYSTEMS" (PDF). Doctor of Philosophy in Computer Sciences. University of Wisconsin-Madison. Retrieved 9 June 2012.
  14. "Parity Lost and Parity Regained".
  15. "An Analysis of Data Corruption in the Storage Stack" (PDF).
  16. "Impact of Disk Corruption on Open-Source DBMS" (PDF).
  17. Kadav, Asim; Rajimwale, Abhishek. "Reliability Analysis of ZFS" (PDF).
  18. Yupu Zhang; Abhishek Rajimwale; Andrea C. Arpaci-Dusseau; Remzi H. Arpaci-Dusseau. "End-to-end Data Integrity for File Systems: A ZFS Case Study" (PDF). Madison: Computer Sciences Department, University of Wisconsin. p. 14. Retrieved December 6, 2010.
  19. Larabel, Michael. "Benchmarking ZFS and UFS On FreeBSD vs. EXT4 & Btrfs On Linux". Phoronix Media 2012. Retrieved 21 November 2012.
  20. Larabel, Michael. "Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS?". Phoronix Media 2012. Retrieved 21 November 2012.
  21. 1 2 3 Bonwick, Jeff (2005-12-08). "ZFS End-to-End Data Integrity". blogs.oracle.com. Retrieved 2013-09-19.
  22. Cook, Tim (November 16, 2009). "Demonstrating ZFS Self-Healing". blogs.oracle.com. Retrieved 2015-02-01.
  23. Ranch, Richard (2007-05-04). "ZFS, copies, and data protection". blogs.oracle.com. Retrieved 2015-02-02.
  24. "Difference between Desktop edition and RAID (Enterprise) edition drives".
  25. 1 2 3 4 Bonwick, Jeff (2005-11-17). "RAID-Z". Jeff Bonwick's Blog. Oracle Blogs. Retrieved 2015-02-01.
  26. "Why RAID 6 stops working in 2019". ZDNet. February 22, 2010. Retrieved October 26, 2014.
  27. "Actually it's a n-way mirror". c0t0d0s0.org. 2013-09-04. Retrieved 2013-11-19.
  28. "No fsck utility equivalent exists for ZFS. This utility has traditionally served two purposes, those of file system repair and file system validation." "Checking ZFS File System Integrity". Oracle. Retrieved 25 November 2012.
  29. "ZFS Scrubs". freenas.org. Archived from the original on November 27, 2012. Retrieved 25 November 2012.
  30. "You should also run a scrub prior to replacing devices or temporarily reducing a pool's redundancy to ensure that all devices are currently operational." "ZFS Best Practices Guide". solarisinternals.com. Archived from the original on September 5, 2015. Retrieved 25 November 2012.
  31. Jeff Bonwick. "128-bit storage: are you high?". oracle.com. Retrieved May 29, 2015.
  32. 1 2 Bonwick, Jeff (October 31, 2005). "ZFS: The Last Word in Filesystems". blogs.oracle.com. Retrieved June 22, 2013.
  33. "ZFS: Boils the Ocean, Consumes the Moon (Dave Brillhart's Blog)". Retrieved December 19, 2015.
  34. "Solaris ZFS Administration Guide". Oracle Corporation. Retrieved February 11, 2011.
  35. "Encrypting ZFS File Systems".
  36. "Having my secured cake and Cloning it too (aka Encryption + Dedup with ZFS)".
  37. "Solaris ZFS Administration Guide". Oracle Corporation. Retrieved February 11, 2011.
  38. "ZFS Best Practices Guide". Solaris Performance Wiki. Archived from the original on September 28, 2007. Retrieved October 2, 2007.
  39. Leventhal, Adam. "Bug ID: 6854612 triple-parity RAID-Z". Sun Microsystems. Archived from the original on July 27, 2009. Retrieved July 17, 2009.
  40. Leventhal, Adam (July 16, 2009). "6854612 triple-parity RAID-Z". zfs-discuss (Mailing list). Archived from the original on December 23, 2009. Retrieved July 17, 2009.
  41. "WHEN TO (AND NOT TO) USE RAID-Z". Oracle. Retrieved 13 May 2013.
  42. "Solaris ZFS Enables Hybrid Storage Pools—Shatters Economic and Performance Barriers" (PDF). Sun.com. September 7, 2010. Retrieved November 4, 2011.
  43. "Brendan's blog » ZFS L2ARC". Dtrace.org. Retrieved 2012-10-05.
  44. "Solaris ZFS Performance Tuning: Synchronous Writes and the ZIL". Constantin.glez.de. 2010-07-20. Retrieved 2012-10-05.
  45. "ZFS On-Disk Specification" (PDF). Sun Microsystems, Inc. 2006. Archived from the original (PDF) on December 30, 2008. See section 2.4.
  46. Eric Sproul (2009-05-21). "ZFS Nuts and Bolts". slideshare.net. pp. 30–31. Retrieved 2014-06-08.
  47. "Unix.com". Unix.com. November 13, 2007. Retrieved November 4, 2011.
  48. "ZFS Deduplication". blogs.oracle.com.
  49. Gary Sims (4 January 2012). "Building ZFS Based Network Attached Storage Using FreeNAS 8" (Blog). TrainSignal Training. TrainSignal, Inc. Retrieved 9 June 2012.
  50. Ray Van Dolson (May 2011). "[zfs-discuss] Summary: Deduplication Memory Requirements". zfs-discuss mailing list. Archived from the original on 2012-04-25.
  51. "ZFSTuningGuide".
  52. Chris Mellor (October 12, 2012). "GreenBytes brandishes full-fat clone VDI pumper". The Register. Retrieved August 29, 2013.
  53. Chris Mellor (June 1, 2012). "Newcomer gets out its box, plans to sell it cheaply to all comers". The Register. Retrieved August 29, 2013.
  54. Chris Mellor (2014-12-11). "Dedupe, dedupe... dedupe, dedupe, dedupe: Oracle polishes ZFS diamond". The Register. Retrieved 2014-12-17.
  55. "Solaris ZFS Administration Guide". Chapter 6 Managing ZFS File Systems. Archived from the original on February 5, 2011. Retrieved March 17, 2009.
  56. 1 2 "Smokin' Mirrors". blogs.oracle.com. May 2, 2006. Retrieved February 13, 2012.
  57. "ZFS Block Allocation". Jeff Bonwick's Weblog. November 4, 2006. Retrieved February 23, 2007.
  58. "Ditto Blocks — The Amazing Tape Repellent". Flippin' off bits Weblog. May 12, 2006. Retrieved March 1, 2007.
  59. "Adding new disks and ditto block behaviour". Archived from the original on August 23, 2011. Retrieved October 19, 2009.
  60. "OpenSolaris.org". Sun Microsystems. Archived from the original on May 8, 2009. Retrieved May 22, 2009.
  61. End-to-end data integrity for file systems: a ZFS case study, Zhang et al 2010 direct link
  62. http://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271. Missing or empty |title= (help)
  63. "Bug ID 4852783: reduce pool capacity". OpenSolaris Project. Archived from the original on June 29, 2009. Retrieved March 28, 2009.
  64. Goebbels, Mario (April 19, 2007). "Permanently removing vdevs from a pool". zfs-discuss (Mailing list). Archived from the original on April 1, 2013.
  65. "Expand-O-Matic RAID Z". Adam Leventhal. April 7, 2008.
  66. "zpool(1M)". Download.oracle.com. June 11, 2010. Retrieved November 4, 2011.
  67. Leventhal, Adam. "Triple-Parity RAID Z". Adam Leventhal's blog. Retrieved 19 December 2013.
  68. brendan (December 2, 2008). "A quarter million NFS IOPS". Oracle Sun. Retrieved January 28, 2012.
  69. "Oracle Has Killed OpenSolaris". Techie Buzz. August 14, 2010. Retrieved July 17, 2013.
  70. "oi_151a_prestable5 Release Notes". Retrieved May 23, 2016.
  71. "Upgrading from OpenSolaris". Retrieved September 24, 2011.
  72. "OpenZFS on OS X". openzfsonosx.org. 2014-09-29. Retrieved 2014-11-23.
  73. 1 2 "Features – OpenZFS – Feature flags". OpenZFS. Retrieved 22 September 2013.
  74. "MacZFS: Official Site for the Free ZFS for Mac OS". code.google.com. MacZFS. Retrieved 2014-03-02.
  75. "ZEVO Wiki Site/ZFS Pool And Filesystem Versions". GreenBytes, Inc. 2012-09-15. Retrieved 22 September 2013.
  76. "Github zfs-port branch".
  77. "NetBSD Google Summer of Code projects: ZFS".
  78. Dawidek, Paweł (April 6, 2007). "ZFS committed to the FreeBSD base". Retrieved April 6, 2007.
  79. "Revision 192498". May 20, 2009. Retrieved May 22, 2009.
  80. "ZFS v13 in 7-STABLE". May 21, 2009. Archived from the original on May 27, 2009. Retrieved May 22, 2009.
  81. "iSCSI target for FreeBSD". Retrieved August 6, 2011.
  82. "FreeBSD 8.0-RELEASE Release Notes". FreeBSD. Retrieved November 27, 2009.
  83. "FreeBSD 8.0-STABLE Subversion logs". FreeBSD. Retrieved February 5, 2010.
  84. "FreeBSD 8.2-RELEASE Release Notes". FreeBSD. Retrieved March 9, 2011.
  85. "HEADS UP: ZFS v28 merged to 8-STABLE". June 6, 2011. Retrieved June 11, 2011.
  86. "FreeBSD 8.3-RELEASE Announcement". Retrieved June 11, 2012.
  87. Pawel Jakub Dawidek. "ZFS v28 is ready for wider testing.". Retrieved August 31, 2010.
  88. "FreeBSD 9.0-RELEASE Release Notes". FreeBSD. Retrieved January 12, 2012.
  89. "FreeBSD 9.2-RELEASE Release Notes". FreeBSD. Retrieved September 30, 2013.
  90. "NAS4Free: Features". Retrieved 13 January 2015.
  91. "Debian GNU/kFreeBSD FAQ". Is there ZFS support?. Retrieved 2013-09-24.
  92. "Debian GNU/kFreeBSD FAQ". Can I use ZFS as root or /boot file system?. Retrieved 2013-09-24.
  93. "Debian GNU/kFreeBSD FAQ". What grub commands are necessary to boot Debian/kFreeBSD from a zfs root?. Retrieved 2013-09-24.
  94. Larabel, Michael (2010-09-10). "Debian GNU/kFreeBSD Becomes More Interesting". Phoronix. Retrieved 2013-09-24.
  95. Eben Moglen; Mishi Choudharyl (February 26, 2016). "The Linux Kernel, CDDL and Related Issues". softwarefreedom.org. Retrieved March 30, 2016.
  96. Bradley M. Kuhn; Karen M. Sandler (February 25, 2016). "GPL Violations Related to Combining ZFS and Linux". sfconservancy.org. Retrieved March 30, 2016.
  97. "Linus on GPLv3 and ZFS". Lwn.net. June 12, 2007. Retrieved November 4, 2011.
  98. Ryan Paul (June 9, 2010). "Uptake of native Linux ZFS port hampered by license conflict". Ars Technica. Retrieved July 1, 2014.
  99. Aditya Rajgarhia & Ashish Gehani (November 23, 2012). "Performance and Extension of User Space File Systems" (PDF).
  100. Behlendorf, Brian (2013-05-28). "spl/zfs-0.6.1 released". zfs-announce mailing list. Retrieved 2013-10-09.
  101. "ZFS on Linux". Retrieved 29 August 2013.
  102. 1 2 Matt Ahrens; Brian Behlendorf (2013-09-17). "LinuxCon 2013: OpenZFS" (PDF). linuxfoundation.org. Retrieved 2013-11-13.
  103. "ZFS on Linux". zfsonlinux.org. Retrieved 2014-08-13.
  104. Darshin (August 24, 2010). "ZFS Port to Linux (all versions)". Retrieved August 31, 2010.
  105. "Where can I get the ZFS for Linux source code?". Archived from the original on October 8, 2011. Retrieved 29 August 2013.
  106. Phoronix (November 22, 2010). "Running The Native ZFS Linux Kernel Module, Plus Benchmarks". Retrieved December 7, 2010.
  107. 1 2 "KQ ZFS Linux Is No Longer Actively Being Worked On". June 10, 2011.
  108. "zfs-linux / zfs".
  109. "ZFS – Gentoo documentation". gentoo.org. Retrieved 2013-10-09.
  110. "ZFS root". Slackware ZFS root. SlackWiki.com. Retrieved 2014-08-13.
  111. "ZFS root (builtin)". Slackware ZFS root (builtin). SlackWiki.com. Retrieved 2014-08-13.
  112. Michael Larabel (6 October 2015). "Ubuntu Is Planning To Make The ZFS File-System A "Standard" Offering". Phoronix.
  113. Dustin Kirkland (18 February 2016). "ZFS Licensing and Linux". Ubuntu Insights. Canonical.
  114. Are GPLv2 and CDDL incompatible? on hansenpartnership.com by James E.J. Bottomley "What the above analysis shows is that even though we presumed combination of GPLv2 and CDDL works to be a technical violation, there’s no way actually to prosecute such a violation because we can’t develop a convincing theory of harm resulting. Because this makes it impossible to take the case to court, effectively it must be concluded that the combination of GPLv2 and CDDL, provided you’re following a GPLv2 compliance regime for all the code, is allowable." (23 February 2016)
  115. Moglen, Eben; Choudhary, Mishi (26 February 2016). "The Linux Kernel, CDDL and Related Issues".
  116. GPL Violations Related to Combining ZFS and Linux on sfconservancy.org by Bradley M. Kuhn and Karen M. Sandler "Ultimately, various Courts in the world will have to rule on the more general question of Linux combinations. Conservancy is committed to working towards achieving clarity on these questions in the long term. That work began in earnest last year with the VMware lawsuit, and our work in this area will continue indefinitely, as resources permit. We must do so, because, too often, companies are complacent about compliance. While we and other community-driven organizations have historically avoided lawsuits at any cost in the past, the absence of litigation on these questions caused many companies to treat the GPL as a weaker copyleft than it actually is." (February 25, 2016)
  117. GPL Violations Related to Combining ZFS and Linux on sfconservancy.org by Bradley M. Kuhn and Karen M. Sandler "Conservancy (as a Linux copyright holder ourselves), along with the members of our coalition in the GPL Compliance Project for Linux Developers, all agree that Canonical and others infringe Linux copyrights when they distribute zfs.ko."
  118. Ubuntu 16.04 LTS arrives today complete with forbidden ZFS on the theregister.com (April 21, 2016)
  119. "ZFS filesystem will be built into Ubuntu 16.04 LTS by default". Ars Technica.
  120. Larabel, Michael. "Taking ZFS For A Test Drive On Ubuntu 16.04 LTS". phoronix. Phoronix Media. Retrieved 25 April 2016.
  121. "How to install ubuntu mate onto single sdd with zfs as main fs". Ubuntu MATE. ubuntu-mate.community. Retrieved 25 April 2016.
  122. Brown, David. "A Conversation with Jeff Bonwick and Bill Moore". ACM Queue. Association for Computing Machinery. Retrieved 17 November 2015.
  123. "ZFS: the last word in file systems". Sun Microsystems. September 14, 2004. Archived from the original on April 28, 2006. Retrieved April 30, 2006.
  124. Matthew Ahrens (November 1, 2011). "ZFS 10 year anniversary". Retrieved July 24, 2012.
  125. "Sun Celebrates Successful One-Year Anniversary of OpenSolaris". Sun Microsystems. June 20, 2006.
  126. Jeff Bonwick (May 3, 2006). "You say zeta, I say zetta". Jeff Bonwick's Blog. Retrieved April 23, 2012.
  127. "Oracle and NetApp dismiss ZFS lawsuits". theregister.co.uk. 2010-09-09. Retrieved 2013-12-24.
  128. "OpenZFS History". OpenZFS. Retrieved 2013-09-24.
  129. "illumos FAQs". illumos. Retrieved 2013-09-24.
  130. "Sun rolls out its own storage appliances". techworld.com.au. 2008-11-11. Retrieved 2013-11-13.
  131. Chris Mellor (2013-10-02). "Oracle muscles way into seat atop the benchmark with hefty ZFS filer". theregister.co.uk. Retrieved 2014-07-07.
  132. "Unified ZFS Storage Appliance built in Silicon Valley by iXsystem". ixsystems.com. Retrieved 2014-07-07.
  133. "ReadyDATA 516 - Unified Network Storage" (PDF). netgear.com. Retrieved 2014-07-07.
  134. "Solaris ZFS Administration Guide, Appendix A ZFS Version Descriptions". Oracle Corporation. 2010. Retrieved February 11, 2011.
  135. "Oracle Solaris ZFS Version Descriptions". Oracle Corporation. Retrieved 2013-09-23.
  136. Siden, Christopher (January 2012). "ZFS Feature Flags" (PDF). Illumos Meetup. Delphix. p. 4. Retrieved 2013-09-22.
  137. "/usr/src/uts/common/sys/fs/zfs.h (line 338)". illumos (GitHub). Retrieved 2013-11-16.
  138. "/usr/src/uts/common/fs/zfs/zfeature.c (line 89)". illumos (GitHub). Retrieved 2013-11-16.
  139. 1 2 3 "While under Sun Microsystems' control, there were bi-weekly snapshots of Solaris Nevada (the codename for the next-generation Solaris OS to eventually succeed Solaris 10) and this new code was then pulled into new OpenSolaris preview snapshots available at Genunix.org. The stable releases of OpenSolaris are based off of these Nevada builds." Larabel, Michael. "It Looks Like Oracle Will Stand Behind OpenSolaris". Phoronix Media. Retrieved 21 November 2012.
  140. Ljubuncic, Igor (23 May 2011). "OpenIndiana — there's still hope". DistroWatch.
  141. "Welcome to Project OpenIndiana!". Project OpenIndiana. 10 September 2010. Retrieved 14 September 2010.
  142. "Porting ZFS to OSX". zfs-discuss. April 27, 2006. Archived from the original on May 15, 2006. Retrieved April 30, 2006.
  143. "Apple: Leopard offers limited ZFS read-only". MacNN. June 12, 2007. Retrieved June 23, 2007.
  144. "Apple delivers ZFS Read/Write Developer Preview 1.1 for Leopard". Ars Technica. October 7, 2007. Retrieved October 7, 2007.
  145. Ché Kristo (November 18, 2007). "ZFS Beta Seed v1.1 will not install on Leopard.1 (10.5.1) " ideas are free". Archived from the original on December 24, 2007. Retrieved December 30, 2007.
  146. ZFS.macosforge.org Archived November 2, 2009, at the Wayback Machine.
  147. http://alblue.blogspot.com/2008/11/zfs-119-on-mac-os-x.html |title=Alblue.blogspot.com
  148. "Snow Leopard (archive.org cache)". July 21, 2008. Archived from the original on 2008-07-21.
  149. "Snow Leopard". June 9, 2009. Retrieved June 10, 2008.
  150. "maczfs – Official Site for the Free ZFS for Mac OS – Google Project Hosting". Google. Retrieved July 30, 2012.
  151. "zfs-macos | Google Groups". Google. Retrieved November 4, 2011.
  152. "Distribution – OpenZFS". OpenZFS. Retrieved 17 September 2013.

Bibliography

This article is issued from Wikipedia - version of the 11/21/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.