“Btrfs”的意思、由来-开放百科全书

Btrfs is intended to address the lack of pooling, snapshots, checksums, and integral multi-device spanning in Linux file systems.^[9] Chris Mason, the principal Btrfs author, has stated that its goal was "to let Linux scale for the storage that will be available. Scaling is not just about addressing the storage but also means being able to administer and to manage it with a clean interface that lets people see what's being used and makes it more reliable".^[12]

History

The core data structure of Btrfs{{mdashb}}the copy-on-write B-tree{{mdashb}}was originally proposed by IBM researcher Ohad Rodeh at a presentation at USENIX 2007.{{r|rodeh-1}} Chris Mason, an engineer working on ReiserFS for SUSE at the time, joined Oracle later that year and began work on a new file system based on these B-trees.{{r|joinfb}}

In 2008, the principal developer of the ext3 and ext4 file systems, Theodore Ts'o, stated that although ext4 has improved features, it is not a major advance; it uses old technology and is a stop-gap. Ts'o said that Btrfs is the better direction because "it offers improvements in scalability, reliability, and ease of management".^[13] Btrfs also has "a number of the same design ideas that reiser3/4 had".^[14]

Btrfs 1.0, with finalized on-disk format, was originally slated for a late-2008 release,^[15] and was finally accepted into the Linux kernel mainline in 2009.^[16] Several Linux distributions began offering Btrfs as an experimental choice of root file system during installation.^[17]^[18]^[19]

In July 2011, Btrfs automatic defragmentation and scrubbing features were merged into version 3.0 of the Linux kernel mainline.^[26] Besides Mason at Oracle, Miao Xie at Fujitsu contributed performance improvements.^[20] In June 2012, Chris Mason left Oracle for Fusion-io, which he left a year later with Josef Bacik to join Facebook; while at both companies, Mason continued his work on Btrfs.^[21]^[29]

In summer 2012, several Linux distributions moved Btrfs from experimental to production or supported status.^[22]^[23]

In 2015, Btrfs was adopted as the default filesystem for SUSE Linux Enterprise Server 12.^[24]

In August 2017, the release notes of Red Hat Enterprise Linux 7.4 indicated that Red Hat was going to stop supporting Btrfs; RHEL 7.4 includes updates for Btrfs from upstream, but there are no further updates planned to be included, and Btrfs will be removed from Red Hat Enterprise Linux in a future major release.^[25] Suse reaffirmed its commitment to Btrfs.^[26]

Features

Implemented

As of version 4.12 of the Linux kernel, Btrfs implements the following features:^[35]^[27]

Implemented but not recommended for production use

Planned but not yet implemented^[35]

In 2009, Btrfs was expected to offer a feature set comparable to ZFS, developed by Sun Microsystems.^[60] After Oracle's acquisition of Sun in 2009, Mason and Oracle decided to continue with Btrfs development.^[43]

Cloning

Btrfs provides a clone operation that atomically creates a copy-on-write snapshot of a file. Such cloned files are sometimes referred to as reflinks, in light of the associated Linux kernel system calls.^[44]

By cloning, the file system does not create a new link pointing to an existing inode; instead, it creates a new inode that initially shares the same disk blocks with the original file. As a result, cloning works only within the boundaries of the same Btrfs file system, but since version 3.6 of the Linux kernel it may cross the boundaries of subvolumes under certain circumstances.^[63]^[45] The actual data blocks are not duplicated; at the same time, due to the copy-on-write (CoW) nature of Btrfs, modifications to any of the cloned files are not visible in the original file and vice versa.^[65]

Cloning should not be confused with hard links, which are directory entries that associate multiple file names with actual files on a file system. While hard links can be taken as different names for the same file, cloning in Btrfs provides independent files that share their disk blocks.^[65]^[46]

Support for this Btrfs feature was added in version 7.5 of the GNU coreutils, via the --reflink option to the cp command.^[47]^[48]

Subvolumes and snapshots

A Btrfs subvolume can be thought of as a separate POSIX file namespace, mountable separately by passing subvol or subvolid options to the {{man|8|mount|man.cx||inline}} utility. It can also be accessed by mounting the top-level subvolume, in which case subvolumes are visible and accessible as its subdirectories.^[70]

Subvolumes can be created at any place within the file system hierarchy, and they can also be nested. Nested subvolumes appear as subdirectories within their parent subvolumes, similarly to the way a top-level subvolume presents its subvolumes as subdirectories. Deleting a subvolume is not possible until all subvolumes below it in the nesting hierarchy are deleted; as a result, top-level subvolumes cannot be deleted.^[71]

Any Btrfs file system always has a default subvolume, which is initially set to be the top-level subvolume, and is mounted by default if no subvolume selection option is passed to mount. The default subvolume can be changed as required.^[71]

A Btrfs snapshot is a subvolume that shares its data (and metadata) with some other subvolume, using Btrfs' copy-on-write capabilities, and modifications to a snapshot are not visible in the original subvolume. Once a writable snapshot is made, it can be treated as an alternate version of the original file system. For example, to roll back to a snapshot, a modified original subvolume needs to be unmounted and the snapshot needs to be mounted in its place. At that point, the original subvolume may also be deleted.^[70]

The copy-on-write (CoW) nature of Btrfs means that snapshots are quickly created, while initially consuming very little disk space. Since a snapshot is a subvolume, creating nested snapshots is also possible. Taking snapshots of a subvolume is not a recursive process; thus, if a snapshot of a subvolume is created, every subvolume or snapshot that the subvolume already contains is mapped to an empty directory of the same name inside the snapshot.^[70]^[71]

Taking snapshots of a directory is not possible, as only subvolumes can have snapshots. However, there is a workaround that involves reflinks spread across subvolumes: a new subvolume is created, containing cross-subvolume reflinks to the content of the targeted directory. Having that available, a snapshot of this new volume can be created.^[63]

A subvolume in Btrfs is quite different from a traditional Logical Volume Manager (LVM) logical volume. With LVM, a logical volume is a separate block device, while a Btrfs subvolume is not and it cannot be treated or used that way.^[70] Making dd or LVM snapshots of btrfs leads to dataloss if either the original or the copy is mounted while both are on the same computer.^[49]

Send–receive

Given any pair of subvolumes (or snapshots), Btrfs can generate a binary diff between them (by using the btrfs send command) that can be replayed later (by using btrfs receive), possibly on a different Btrfs file system. The send–receive feature effectively creates (and applies) a set of data modifications required for converting one subvolume into another.^[49]^[80]

The send/receive feature can be used with regularly scheduled snapshots for implementing a simple form of file system master–slave replication, or for the purpose of performing incremental backups.^[49]^[80]

Quota groups

A quota group (or qgroup) imposes an upper limit to the space a subvolume or snapshot may consume. A new snapshot initially consumes no quota because its data is shared with its parent, but thereafter incurs a charge for new files and copy-on-write operations on existing files. When quotas are active, a quota group is automatically created with each new subvolume or snapshot. These initial quota groups are building blocks which can be grouped (with the btrfs qgroup command) into hierarchies to implement quota pools.^[52]

Quota groups only apply to subvolumes and snapshots, while having quotas enforced on individual subdirectories, users, or user groups is not possible. However, workarounds are possible by using different subvolumes for all users or user groups that require a quota to be enforced.

In-place conversion from ext2/3/4 and reiserfs

As the result of having very little metadata anchored in fixed locations, Btrfs can warp to fit unusual spatial layouts of the backend storage devices. The btrfs-convert tool exploits this ability to do an in-place conversion of an ext2/3/4 or ReiserFS file system, by nesting the equivalent Btrfs metadata in its unallocated space—while preserving an unmodified copy of the original file system.^[84]

The conversion involves creating a copy of the whole ext2/3/4 metadata, while the Btrfs files simply point to the same blocks used by the ext2/3/4 files. This makes the bulk of the blocks shared between the two filesystems before the conversion becomes permanent. Thanks to the copy-on-write nature of Btrfs, the original versions of the file data blocks are preserved during all file modifications. Until the conversion becomes permanent, only the blocks that were marked as free in ext2/3/4 are used to hold new Btrfs modifications, meaning that the conversion can be undone at any time (although doing so will erase any changes made after the conversion to Btrfs).^[84]

All converted files are available and writable in the default subvolume of the Btrfs. A sparse file holding all of the references to the original ext2/3/4 filesystem is created in a separate subvolume, which is mountable on its own as a read-only disk image, allowing both original and converted file systems to be accessed at the same time. Deleting this sparse file frees up the space and makes the conversion permanent.^[84]

As of June 2015 and 4.x versions of the Linux kernel mainline, the in-place ext3/4 conversion was considered untested and rarely used.^[84] The feature, however, was rewritten from scratch in 2016 for btrfs-progs 4.6.^[37] and is considered stable since then.

In-place conversion from ReiserFS was introduced in September 2017 with kernel 4.13.^[50]

Union mounting / seed devices

When creating a new Btrfs, an existing Btrfs can be used as a read-only "seed" file system.^[51] The new file system will then act as a copy-on-write overlay on the seed, as a form of union mounting. The seed can be later detached from the Btrfs, at which point the rebalancer will simply copy over any seed data still referenced by the new file system before detaching. Mason has suggested this may be useful for a Live CD installer, which might boot from a read-only Btrfs seed on an optical disc, rebalance itself to the target partition on the install disk in the background while the user continues to work, then eject the disc to complete the installation without rebooting.^[91]

Encryption

In his 2009 interview, Chris Mason stated that support for encryption was planned for Btrfs.^[52] In the meantime, a workaround for combining encryption with Btrfs is to use a full-disk encryption mechanism such as dm-crypt / LUKS on the underlying devices and to create the Btrfs filesystem on top of that layer.

Checking and recovery

Unix systems traditionally rely on "fsck" programs to check and repair filesystems. This functionality is implemented via the btrfs check program. Since version 4.0 this functionality is deemed relatively stable. However, as of August 2017, the btrfs documentation suggests that it be used only after having tried other recovery methods.^[93]

There is another tool, named btrfs-restore, that can be used to recover files from an unmountable filesystem, without modifying the broken filesystem itself (i.e., non-destructively).^[53]

In normal use, Btrfs is mostly self-healing and can recover from broken root trees at mount time, thanks to making periodic data flushes to permanent storage, by default every 30 seconds. Thus, isolated errors will cause a maximum of 30 seconds of filesystem changes to be lost at the next mount.^[54] This period can be changed by specifying a desired value (in seconds) for the commit mount option.^[55]^[56]

Design

Ohad Rodeh's original proposal at USENIX 2007 noted that B+ trees, which are widely used as on-disk data structures for databases, could not efficiently allow copy-on-write-based snapshots because its leaf nodes were linked together: if a leaf was copy-on-written, its siblings and parents would have to be as well, as would their siblings and parents and so on until the entire tree was copied. He suggested instead a modified B-tree (which has no leaf linkage), with a refcount associated to each tree node but stored in an ad-hoc free map structure and certain relaxations to the tree's balancing algorithms to make them copy-on-write friendly. The result would be a data structure suitable for a high-performance object store that could perform copy-on-write snapshots, while maintaining good concurrency.^[98]

At Oracle later that year, Chris Mason began work on a snapshot-capable file system that would use this data structure almost exclusively—not just for metadata and file data, but also recursively to track space allocation of the trees themselves. This allowed all traversal and modifications to be funneled through a single code path, against which features such as copy-on-write, checksumming and mirroring needed to be implemented only once to benefit the entire file system.^[60]

Btrfs is structured as several layers of such trees, all using the same B-tree implementation. The trees store generic items sorted on a 136-bit key. The first 64 bits of the key are a unique object id. The middle 8 bits are an item type field; its use is hardwired into code as an item filter in tree lookups. Objects can have multiple items of multiple types. The remaining right-hand 64 bits are used in type-specific ways. Therefore, items for the same object end up adjacent to each other in the tree, ordered by type. By choosing certain right-hand key values, objects can further put items of the same type in a particular order.^[60]^[2]

Interior tree nodes are simply flat lists of key-pointer pairs, where the pointer is the logical block number of a child node. Leaf nodes contain item keys packed into the front of the node and item data packed into the end, with the two growing toward each other as the leaf fills up.^[60]

Root tree

Every tree appears as an object in the root tree (or tree of tree roots). Some trees, such as file system trees and log trees, have a variable number of instances, each of which is given its own object id. Trees which are singletons (the data relocation, extent and chunk trees) are assigned special, fixed object ids ≤256. The root tree appears in itself as a tree with object id 1.

Trees refer to each other by object id. They may also refer to individual nodes in other trees as a triplet of the tree's object id, the node's level within the tree and its leftmost key value. Such references are independent of where the tree is actually stored.

File system tree

User-visible files and directories are contained in a file system tree. There is one file system tree per subvolume. Subvolumes can nest, in which case they appear as a directory item (described below) whose data is a reference to the nested subvolume's file system tree.{{Citation needed|date=January 2017}}

Within the file system tree, each file and directory object has an inode item. Extended attributes and ACL entries are stored alongside in separate items.{{Citation needed|date=January 2017}}

Within each directory, directory entries appear as directory items, whose right-hand key values are a CRC32C hash of their filename. Their data is a location key, or the key of the inode item it points to. Directory items together can thus act as an index for path-to-inode lookups, but are not used for iteration because they are sorted by their hash, effectively randomly permuting them. This means user applications iterating over and opening files in a large directory would thus generate many more disk seeks between non-adjacent files—a notable performance drain in other file systems with hash-ordered directories such as ReiserFS,^[57] ext3 (with Htree-indexes enabled^[58]) and ext4, all of which have TEA-hashed filenames. To avoid this, each directory entry has a directory index item, whose right-hand key value of the item is set to a per-directory counter that increments with each new directory entry. Iteration over these index items thus returns entries in roughly the same order as they are stored on disk.

Besides inode items, files and directories also have a reference item whose right-hand key value is the object id of their parent directory. The data part of the reference item is the filename that inode is known by in that directory. This allows upward traversal through the directory hierarchy by providing a way to map inodes back to paths.{{Citation needed|date=January 2017}}

Files with hard links in multiple directories have multiple reference items, one for each parent directory. Files with multiple hard links in the same directory pack all of the links' filenames into the same reference item. This was a design flaw that limited the number of same-directory hard links to however many could fit in a single tree block. (On the default block size of 4 KiB, an average filename length of 8 bytes and a per-filename header of 4 bytes, this would be less than 350.) Applications which made heavy use of multiple same-directory hard links, such as git, GNUS, GMame and BackupPC were later observed to fail after hitting this limit.^[105] The limit was eventually removed^[59] (and as of October 2012 has been merged^[60] pending release in Linux 3.7) by introducing spillover extended reference items to hold hard link filenames which could not otherwise fit.

Extents

File data is kept outside the tree in extents, which are contiguous runs of disk blocks. Extent blocks default to 4KiB in size, do not have headers and contain only (possibly compressed) file data. In compressed extents, individual blocks are not compressed separately; rather, the compression stream spans the entire extent.

Files have extent data items to track the extents which hold their contents. The item's right-hand key value is the starting byte offset of the extent. This makes for efficient seeks in large files with many extents, because the correct extent for any given file offset can be computed with just one tree lookup.

Snapshots and cloned files share extents. When a small part of a large such extent is overwritten, the resulting copy-on-write may create three new extents: a small one containing the overwritten data, and two large ones with unmodified data on either side of the overwrite. To avoid having to re-write unmodified data, the copy-on-write may instead create bookend extents, or extents which are simply slices of existing extents. Extent data items allow for this by including an offset into the extent they are tracking: items for bookends are those with non-zero offsets.^[2]

If the file data is small enough to fit inside a tree node, it is instead pulled in-tree and stored inline in the extent data item. Each tree node is stored in its own tree block—a single uncompressed block with a header. The tree block is regarded as a free-standing, single-block extent.

Extent allocation tree

The extent allocation tree acts as an allocation map for the file system. Unlike other trees, items in this tree do not have object ids and represent regions of space: their left-hand and right-hand key values are the starting offsets and lengths of the regions they represent.

The file system zones its allocated space into block groups, which are variable-sized allocation regions that alternate successively between preferring metadata extents (tree nodes) and data extents (file contents). The default ratio of data to metadata block groups is 1:2. They are intended to work like the Orlov block allocator and block groups in ext3 in allocating related files together and resisting fragmentation by leaving allocation gaps between groups. (ext3 block groups, however, have fixed locations computed from the size of the file system, whereas those in Btrfs are dynamic and are created as needed.) Each block group is associated with a block group item. Inode items in the file system tree include a reference to their current block group.^[2]

Extent items contain a back-reference to the tree node or file occupying that extent. There may be multiple back-references if the extent is shared between snapshots. If there are too many back-references to fit in the item, they spill out into individual extent data reference items. Tree nodes, in turn, have back-references to their containing trees. This makes it possible to find which extents or tree nodes are in any region of space by doing a B-tree range lookup on a pair of offsets bracketing that region, then following the back-references. For relocating data, this allows an efficient upwards traversal from the relocated blocks to quickly find and fix all downwards references to those blocks, without having to walk the entire file system. This, in turn, allows the file system to efficiently shrink, migrate and defragment its storage online.

The extent allocation tree, as with all other trees in the file system, is copy-on-write. Writes to the file system may thus cause a cascade whereby changed tree nodes and file data result in new extents being allocated, causing the extent tree to itself change. To avoid creating a feedback loop, extent tree nodes which are still in memory but not yet committed to disk may be updated in-place to reflect new copy-on-written extents.

In theory, the extent allocation tree makes a conventional free-space bitmap unnecessary because the extent allocation tree acts as a B-tree version of a BSP tree. In practice, however, an in-memory red-black tree of page-sized bitmaps is used to speed up allocations. These bitmaps are persisted to disk (starting in Linux 2.6.37, via the space_cache mount option^[61]) as special extents that are exempt from checksumming and copy-on-write. The extent items tracking these extents are stored in the root tree.

Checksum tree and scrubbing

There is one checksum item per contiguous run of allocated blocks, with per-block checksums packed end-to-end into the item data. If there are more checksums than can fit, they spill rightwards over into another checksum item in a new leaf. If the file system detects a checksum mismatch while reading a block, it first tries to obtain (or create) a good copy of this block from another device{{spaced ndash}} if internal mirroring or RAID techniques are in use.^[113]^[63]

Btrfs can initiate an online check of the entire file system by triggering a file system scrub job that is performed in the background. The scrub job scans the entire file system for integrity and automatically attempts to report and repair any bad blocks it finds along the way.^[113]^[64]

Log tree

An fsync is a request to commit modified data immediately to stable storage. fsync-heavy workloads (like a database or a virtual machine whose running OS fsyncs intensively) could potentially generate a great deal of redundant write I/O by forcing the file system to repeatedly copy-on-write and flush frequently modified parts of trees to storage. To avoid this, a temporary per-subvolume log tree is created to journal fsync-triggered copy-on-writes. Log trees are self-contained, tracking their own extents and keeping their own checksum items. Their items are replayed and deleted at the next full tree commit or (if there was a system crash) at the next remount.

Chunk and device trees

Block devices are divided into physical chunks of 256 MB or more. Physical chunks across multiple devices can be mirrored or striped together into a single logical chunk. These logical chunks are combined into a single logical address space that the rest of the filesystem uses.

The chunk tree tracks this by storing each device therein as a device item and logical chunks as chunk map items, which provide a forward mapping from logical to physical addresses by storing their offsets in the right-hand 64 bits of their key. Chunk map items can be one of several different types:

N is however many block devices still have free space when the chunk is allocated. If N is not large enough for the chosen mirroring/mapping, then the filesystem is effectively out of space.

The device tree is the inverse of the chunk tree, and has device extent items which provide a reverse mapping from byte-ranges of block devices back to logical chunks by storing the device number in the left hand 64-bits and physical offset in the right-hand 64 bits of they key.

These two trees together allow Btrfs to grow, shrink and even change RAID levels without unmounting because they make it possible to efficiently locate the chunks affected by shrink/move operations and then relocate their contents on-the-fly.

The file system, chunks and devices are all assigned a Universally Unique Identifier (UUID). The header of every tree node contains both the UUID of its containing chunk and the UUID of the file system. The chunk and device trees refer to devices and chunks with UUIDs. On filesystems with just a single block device, "dup" is also the default profile for metadata. All this is intended to improve the odds of successful data salvage in the event of media errors).

Relocation trees

Defragmentation, shrinking and rebalancing operations require extents to be relocated. However, doing a simple copy-on-write of the relocating extent will break sharing between snapshots and consume disk space. To preserve sharing, an update-and-swap algorithm is used, with a special relocation tree serving as scratch space for affected metadata. The extent to be relocated is first copied to its destination. Then, by following backreferences upward through the affected subvolume's file system tree, metadata pointing to the old extent is progressively updated to point at the new one; any newly updated items are stored in the relocation tree. Once the update is complete, items in the relocation tree are swapped with their counterparts in the affected subvolume, and the relocation tree is discarded.^[65]

Superblock

All the file system's trees—including the chunk tree itself—are stored in chunks, creating a potential bootstrapping problem when mounting the file system. To bootstrap into a mount, a list of physical addresses of chunks belonging to the chunk and root trees must be stored in the superblock.^[66]

Superblock mirrors are kept at fixed locations:^[67] 64 KiB into every block device, with additional copies at 64 MiB, 256 GiB and 1 PiB. When a superblock mirror is updated, its generation number is incremented. At mount time, the copy with the highest generation number is used. All superblock mirrors are updated in tandem, except in SSD mode which alternates updates among mirrors to provide some wear levelling.

See also

Notes

References

1. ^{{cite web |url=https://btrfs.wiki.kernel.org/index.php/Contributors |title=Btrfs Contributors at kernel.org |date=2016-01-18| publisher=kernel.org |accessdate=2016-01-20}}
2. ^{{cite web | url = https://lwn.net/Articles/397442/ | title = File creation times | date = 2010-07-26 | accessdate = 2015-08-15 | author = Jonathan Corbet | publisher = LWN.net}}
3. ^https://btrfs.wiki.kernel.org/index.php/On-disk_Format#Basic_Structures
4. ^{{cite web|url=https://btrfs.wiki.kernel.org|title=btrfs Wiki|work=kernel.org|accessdate=19 April 2015}}
5. ^https://kernelnewbies.org/Linux_4.14
6. ^{{cite web|url=https://btrfs.wiki.kernel.org/index.php/Deduplication|title=Deduplication|work=kernel.org|accessdate=19 April 2015}}
7. ^{{cite web|url=https://reactos.org/project-news/reactos-041-released|title=ReactOS 0.4.1 Released|work=reactos.org|accessdate=11 August 2016}}
8. ^http://streaming.oracle.com/ebn/podcasts/media/20209545_Oracle-Linux-7.mp4
9. ^{{ cite video | first = Valerie |last=Henson | title = Chunkfs: Fast file system check and repair | date = 31 January 2008 | url = http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-262.ogg | time = 18m 49s | quote = It's called Butter FS or B-tree FS, but all the cool kids say Butter FS | location = Melbourne, Australia | accessdate = 2008-02-05 }}
10. ^{{ cite video | first = Valerie |last=Henson | title = Chunkfs: Fast file system check and repair | date = 31 January 2008 | url = http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-262.ogg | time = 18m 49s | quote = It's called Butter FS or B-tree FS, but all the cool kids say Butter FS | location = Melbourne, Australia | accessdate = 2008-02-05 }}
11. ^{{cite web |title = Linux kernel commit changing stability status in fs/btrfs/Kconfig | url = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4204617d142c0887e45fda2562cb5c58097b918e | accessdate = 2019-02-08 }}
12. ^{{cite web |title=A Better File System for Linux? |first=Sean Michael |last=Kerner |date=30 October 2008 |accessdate=30 October 2008 |work=InternetNews.com |url=http://www.internetnews.com/dev-news/article.php/3781676/A+Better+File+System+for+Linux.htm |archiveurl=https://www.webcitation.org/68elQlAN4?url=http://www.internetnews.com/dev-news/article.php/3781676/A%20Better%20File%20System%20for%20Linux.htm |archivedate=24 June 2012 |deadurl=no |df=dmy }}
13. ^{{ cite journal |url=https://arstechnica.com/open-source/news/2009/04/linux-collaboration-summit-the-kernel-panel.ars |title=Panelists ponder the kernel at Linux Collaboration Summit |first=Ryan |last=Paul |date=13 April 2009 |accessdate=2009-08-22 |publisher=Ars Technica{{inconsistent citations}} |archiveurl=https://www.webcitation.org/68elXKsj7?url=http://arstechnica.com/information-technology/2009/04/linux-collaboration-summit-the-kernel-panel/ |archivedate=24 June 2012 |deadurl=yes |df=dmy }}
14. ^{{ cite mailing list | title = Re: reiser4 for 2.6.27-rc1 | first = Theodore |last=Ts'o | url = https://lkml.org/lkml/2008/8/1/217 | date = 1 August 2008 | accessdate = 2010-12-31 | mailinglist = linux-kernel }}
15. ^{{cite web | url = http://btrfs.wiki.kernel.org/index.php/Development_timeline |deadurl= yes | title = Development timeline | work= Btrfs wiki | date = 11 December 2008 | accessdate = 5 November 2011 | archivedate= 20 December 2008 |archiveurl= https://web.archive.org/web/20081220083235/http://btrfs.wiki.kernel.org/index.php/Development_timeline }}
16. ^{{ cite news | url = http://www.linux-magazine.com/Online/News/Kernel-2.6.29-Corbet-Says-Btrfs-Next-Generation-Filesystem | title = Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem |first= Britta |last=Wuelfing |work= Linux Magazine | date = 12 January 2009 | accessdate= 5 November 2011 }}
17. ^{{cite web |title=Red Hat Enterprise Linux 6 documentation: Technology Previews |url=http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html#id4452791 |access-date=21 January 2011 |archive-url=https://web.archive.org/web/20110528160211/http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html#id4452791#id4452791 |archive-date=28 May 2011 |dead-url=yes |df=dmy-all }}
18. ^{{cite web |title=Fedora Weekly News Issue 276 |url=http://fedoraproject.org/wiki/FWN/LatestIssue#What.27s_new_in_Fedora_15_.28Lovelock.29.3F |date=25 May 2011}}
19. ^{{ cite press release | url=http://www.debian.org/News/2011/20110205a.en.html | title=Debian 6.0 "Squeeze" released | date=6 February 2011 | publisher=Debian | quote=Support has also been added for the ext4 and Btrfs filesystems... | accessdate=2011-02-08}}
20. ^{{ cite news |title= Kernel Log: Coming in 3.0 (Part 2) - Filesystems |first=Thorsten |last=Leemhuis |work= The H Open |date= 21 June 2011 |url= http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-0-Part-2-Filesystems-1263681.html |accessdate= 8 November 2011 }}
21. ^{{cite web |url=http://www.itwire.com/business-it-news/open-source/62417-faecbook-lures-top-btrfs-hackers|title=iTWire|author=Sam Varghese|work=itwire.com|accessdate=19 April 2015}}
22. ^{{cite web|url=http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11-SP2/#fate-306585|title=SLES 11 SP2 Release Notes|date=21 August 2012|accessdate=2012-08-29}}
23. ^{{cite web|url=http://www.oracle.com/us/technologies/linux/025994.htm|title=Oracle Linux Technical Information|accessdate=2012-11-14}}
24. ^{{cite web|url=https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221|title=SUSE Linux Enterprise Server 12 Release Notes|date=2015-11-05|accessdate=2016-01-20}}
25. ^{{cite web|url=https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html|title=Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality|date=2017-08-01|accessdate=2017-08-15}}
26. ^{{cite web|url=https://www.suse.com/communities/blog/butter-bei-die-fische/|title=Butter bei die Fische!|author=mge1512|website=suse.com|date=2017-08-23|accessdate=2017-08-24}}
27. ^{{cite web |title = Btrfs Wiki: Changelog |date=2013-11-08 |accessdate=2013-11-27 |url=https://btrfs.wiki.kernel.org/index.php/Changelog |website=btrfs.wiki.kernel.org}}
28. ^{{cite web | url=https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-check | title=Manpage btrfs-check}}
29. ^{{cite web | url = https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices | title = Using Btrfs with Multiple Devices | date = 2013-11-07 | accessdate = 2013-11-20 | website = kernel.org}}
30. ^{{cite web|url=https://btrfs.wiki.kernel.org|title=btrfs Wiki|work=kernel.org|accessdate=19 April 2015}}
31. ^https://kernelnewbies.org/Linux_4.14
32. ^{{cite web | url = https://btrfs.wiki.kernel.org/index.php/Compression | title = Compression | date = 2013-06-25 | accessdate = 2014-04-01 | website = kernel.org}}
33. ^{{cite web | url = https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=63541927c8d11d2686778b1e8ec71c14b4fd53e4 | title = Btrfs: add support for inode properties | date = 2014-01-28 | accessdate = 2014-04-01 | website = kernel.org}}
34. ^{{cite web | url = https://lwn.net/Articles/417617/ | title= btrfs: Readonly snapshots | accessdate = 2011-12-12 }}
35. ^{{cite web | url = https://blogs.oracle.com/otn/save-disk-space-on-linux-by-cloning-files-on-btrfs-and-ocfs2 | title= Save disk space on Linux by cloning files on Btrfs and OCFS2 | accessdate = 2017-08-01 }}
36. ^{{cite web | url = http://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_function_does_Btrfs_use.3F | work = Btrfs wiki | title = Wiki FAQ: What checksum function does Btrfs use? | accessdate = 2009-06-15 }}
37. ^¹{{cite web | url = https://www.spinics.net/lists/linux-btrfs/msg56040.html | title = Btrfs progs release 4.6 | accessdate = 2017-08-01 }}
38. ^{{cite web | title = Btrfs changelog | first = Chris | last = Mason | date = 12 January 2009 | accessdate = 2012-02-12 | url = http://btrfs.ipv5.de/index.php?title=Changelog#Seed_Device_support }}
39. ^{{cite web|title = Btrfs Wiki: Incremental Backup|date = 2013-05-27|accessdate = 2013-11-27|url = https://btrfs.wiki.kernel.org/index.php/Incremental_Backup}}
40. ^{{cite web|title = Btrfs Wiki: Deduplication|date = 2013-09-13|accessdate = 2013-11-27|url = https://btrfs.wiki.kernel.org/index.php/Deduplication}}
41. ^{{cite web | url = https://btrfs.wiki.kernel.org/index.php/RAID56 | title = RAID 5/6 | date = 2016-07-16 | accessdate = 2016-10-01 | author = btrfs | publisher = kernel.org}}
42. ^{{cite web | title=btrfs: lib: raid: New RAID library supporting up to six parities | url=https://lwn.net/Articles/579034/ | first=Andrea | last=Mazzoleni | accessdate=2014-03-16}}
43. ^{{ cite news |date= 22 April 2009 |first=Marcel |last=Hilzinger |title=Future of Btrfs Secured |publisher=Linux Magazine |url=http://www.linux-magazine.com/Online/News/Future-of-Btrfs-Secured |accessdate = 5 November 2011}}
44. ^{{cite web | url = https://lwn.net/Articles/331808/ | title = The two sides of reflink() | date = 2009-05-05 | accessdate = 2013-10-17 | author = Jonathan Corbet | publisher = LWN.net}}
45. ^{{cite web | url = https://github.com/torvalds/linux/commit/362a20c5e27614739c46707d1c5f55c214d164ce | title = btrfs: allow cross-subvolume file clone | accessdate = 2013-11-04 | website = github.com}}
46. ^{{cite web | url = http://www.pixelbeat.org/docs/unix_links.html | title = Symlinks reference names, hardlinks reference meta-data and reflinks reference data | date = 2010-10-27 | accessdate = 2013-10-17 | website = pixelbeat.org}}
47. ^{{cite web | url = http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=NEWS;h=601d73251c49ce36b39f9838aa818c740cf3a10a;hb=af1996dde2d0089117a9e5e7aa543c6e55474b77 | title = GNU coreutils NEWS: Noteworthy changes in release 7.5 | first = Jim | last = Meyering | date = 20 August 2009 | accessdate = 2009-08-30 | website = savannah.gnu.org}}
48. ^{{cite web | url = http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=a1d7469835371ded0ad8e3496bc5a5bebf94ccef | title = cp: accept the --reflink option | first = Giuseppe | last = Scrivano | date = 1 August 2009 | accessdate = 2009-11-02 | website = savannah.gnu.org}}
49. ^https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices
50. ^{{cite web | url = https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-convert | title = btrfs-convert(8) manual page | accessdate = 2018-04-24 }}
51. ^{{cite web | url=https://btrfs.wiki.kernel.org/index.php/Seed-device | title=Seed device }}
52. ^{{cite web | url = http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux | title = A Conversation with Chris Mason on BTRfs: the next generation file system for Linux | date = 2009-06-22 | accessdate = 2014-10-09 | author = Amanda McPherson | publisher = Linux Foundation | quote = In future releases we plan to add online fsck, deduplication, encryption and other features that have been on admin wish lists for a long time. | deadurl = yes | archiveurl = https://www.webcitation.org/68ektBKkv?url=http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux | archivedate = 24 June 2012 | df = dmy-all }}
53. ^{{cite web|title=Restore |url=https://btrfs.wiki.kernel.org/index.php/Restore}}
54. ^{{cite web|url=https://btrfs.wiki.kernel.org/index.php/Problem_FAQ |title=Problem FAQ - btrfs Wiki |website=kernel.org |date=2013-07-31 |accessdate=2014-01-16}}
55. ^{{cite web | url = https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=906c176e541f89ed3c04d0e9af1c7cf7b3cc1adb | title = kernel/git/torvalds/linux.git: Documentation: filesystems: add new btrfs mount options (Linux kernel source tree) | date = 2013-11-21 | accessdate = 2014-02-06 | publisher = kernel.org}}
56. ^{{cite web|url=https://btrfs.wiki.kernel.org/index.php/Mount_options |title=Mount options - btrfs Wiki | website=kernel.org |date=2013-11-12 |accessdate=2014-01-16}}
57. ^{{cite web|url = http://lkml.indiana.edu/hypermail/linux/kernel/0112.0/2019.html|title = Re: Ext2 directory index: ALS paper and benchmarks|work = ReiserFS developers mailing list|first = Hans|last = Reiser|date = 2001-12-07|accessdate = 2009-08-28}}
58. ^{{cite web|url = http://oss.oracle.com/~mason/acp/ |first=Chris |last=Mason |title = Acp|work = Oracle personal web page|accessdate = 2011-11-05}}
59. ^{{citation|title = btrfs: extended inode refs|first = Mark|last = Fasheh|date = 2012-10-09|accessdate = 2012-11-07|url = https://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298|archive-url = https://archive.is/20130415062145/http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298|dead-url = yes|archive-date = 2013-04-15}}
60. ^{{citation|title = Pull btrfs update from Chris Mason|first = Linus|last = Torvalds|date = 2012-10-10|accessdate = 2012-11-07|url = https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5|archive-url = https://archive.is/20130415043758/http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5|dead-url = yes|archive-date = 2013-04-15|work = git.kernel.org}}
61. ^{{cite web| title = Benchmarks Of The Btrfs Space Cache Option|accessdate = 2012-11-16|date = 2010-12-24|first = Michael|last = Larabel|url = https://www.phoronix.com/scan.php?page=article&item=btrfs_space_cache&num=1|publisher = Phoronix}}
62. ^{{cite web | url = https://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_function_does_Btrfs_use.3F | title = FAQ - btrfs Wiki: What checksum function does Btrfs use? | accessdate = 2013-09-19 | publisher = The btrfs Project}}
63. ^{{cite web|last=Salter|first=Jim|title=Bitrot and atomic COWs: Inside "next-gen" filesystems|url=https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/|publisher=Ars Technica|accessdate=15 January 2014|date=15 January 2014}}
64. ^{{cite web | url = https://blogs.oracle.com/wim/entry/btrfs_scrub_go_fix_corruptions | title = btrfs scrub - go fix corruptions with mirror copies please! | date = 2011-09-28 | accessdate = 2013-09-20 | first = Wim | last = Coekaerts}}
65. ^{{citation|title = BTRFS: The Linux B-tree Filesystem|date = 2012-07-09|first1 = Chris|last1 = Mason|first2 = Ohad|last2 = Rodeh|first3 = Josef|last3 = Bacik|publisher = IBM Research|url = http://domino.watson.ibm.com/library/CyberDig.nsf/papers/6E1C5B6A1B6EDD9885257A38006B6130/$File/rj10501.pdf|accessdate = 2012-11-12}}
66. ^{{cite web | url = http://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support |deadurl= yes | first= Chris |last=Mason | work = Btrfs wiki | accessdate = 5 November 2011 | date = 30 April 2008 |title = Multiple device support | archivedate= 20 July 2011 |archiveurl= https://web.archive.org/web/20110720220543/https://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support }}
67. ^{{cite mailing list|url = http://kerneltrap.org/mailarchive/linux-btrfs/2010/4/20/6884623|title = Re: Restoring BTRFS partition|mailinglist = linux-btrfs|date = 2010-04-20|last = Bartell|first = Sean}}
68. ^{{cite web | url = http://users.suse.com/~aj/linux_lfs.html | title = Large File Support in Linux | date = 2005-02-15 | accessdate = 2015-08-12 | author = Andreas Jaeger | website = users.suse.com}}
69. ^{{cite web |url = http://kernel.xc.net/html/linux-2.6.29/x86/LBD |title = Linux kernel configuration help for CONFIG_LBD in 2.6.29 on x86 |accessdate = 2015-08-12 |website = kernel.xc.net |archive-url = https://web.archive.org/web/20150906090823/http://kernel.xc.net/html/linux-2.6.29/x86/LBD# |archive-date = 6 September 2015 |dead-url = yes |df = dmy-all}}
70. ^¹²³⁴{{cite web |title=A Conversation with Chris Mason on BTRfs: the next generation file system for Linux |first=Amanda |last=McPherson |date=22 June 2009 |accessdate=2009-09-01 |publisher=Linux Foundation |url=http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux |archiveurl=https://www.webcitation.org/68ektBKkv?url=http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux |archivedate=24 June 2012 |deadurl=yes |df=dmy }}
71. ^¹²{{cite web | url = http://kernelnewbies.org/Linux_3.0#head-3e596e03408e1d32a7cc381d6f54e87feee22ee4 | title = Linux kernel 3.0, Section 1.1. Btrfs: Automatic defragmentation, scrubbing, performance improvements | date = 2011-07-21 | accessdate = 2016-04-05 | website = kernelnewbies.org}}
72. ^¹{{cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=MTUzNTE|title=Lead Btrfs File-System Developers Join Facebook|work=phoronix.com|accessdate=19 April 2015}}
73. ^¹²³{{cite web |title=Btrfs Wiki: Features |date=2013-11-27 |accessdate=2013-11-27 |url=https://btrfs.wiki.kernel.org/index.php/Main_Page#Features |website=btrfs.wiki.kernel.org}}
74. ^¹²³{{citation|url = https://lwn.net/Articles/506244/|first = Jonathan|last = Corbet|title = Btrfs send/receive|publisher = LWN.net|date = 2012-07-11|accessdate = 2012-11-14}}
75. ^¹²{{citation|url = http://sensille.com/qgroups.pdf|format = PDF|title = Btrfs Subvolume Quota Groups|first = Arne|last = Jansen|year = 2011|publisher = Strato AG|accessdate = 2012-11-14}}
76. ^¹{{cite web | first = Jonathan |last=Corbet | date = 2 November 2011 | accessdate = 12 February 2012 | title = A btrfs update at LinuxCon Europe | url = https://lwn.net/Articles/465160/ }}
77. ^¹²{{cite web|date=21 February 2013|accessdate=21 February 2013|title=Btrfs Project ideas|url=https://btrfs.wiki.kernel.org/index.php/Project_ideas }}
78. ^¹²³⁴{{cite web | url = https://lwn.net/Articles/342892/ | title = A short history of btrfs | publisher = LWN.net | first= Valerie |last=Aurora | date = 22 July 2009 | accessdate = 5 November 2011 }}
79. ^¹²{{cite web | url = https://btrfs.wiki.kernel.org/index.php/UseCases | title = UseCases – btrfs documentation | accessdate = 2013-11-04 | website = kernel.org}}
80. ^¹²{{cite web | url = https://blogs.oracle.com/OTNGarage/entry/save_disk_space_on_linux | title = Save disk space on Linux by cloning files on Btrfs and OCFS2 | date = 2011-08-31 | accessdate = 2013-10-17 | author = Lenz Grimmer | website = oracle.com}}
81. ^¹²³{{cite web | url = http://docs.oracle.com/cd/E37670_01/E37355/html/ol_use_case3_btrfs.html | title = 5.6 Creating Subvolumes and Snapshots [needs update] | year = 2013 | accessdate = 2013-10-31 | website = oracle.com}}
82. ^¹²³⁴{{cite web | url = https://btrfs.wiki.kernel.org/index.php/SysadminGuide | title = SysadminGuide – Btrfs documentation | accessdate = 2013-10-31 | website = kernel.org}}
83. ^¹²{{cite web | url = http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html | title = 5.7 Using the Send/Receive Feature | year = 2013 | accessdate = 2013-10-31 | website = oracle.com}}
84. ^¹²³⁴{{cite web | url = https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3 | title = Conversion from Ext3 (Btrfs documentation) | first = Chris | last = Mason | date = 2015-06-25 | accessdate = 2016-04-22 | website = kernel.org}}
85. ^¹{{citation|url = http://linuxfoundation.ubicast.tv/videos/permalink/123/|title = Btrfs Filesystem: Status and New Features|publisher = Linux Foundation|date = 2012-04-05|accessdate = 2012-11-16|first = Chris|last = Mason}}{{Dead link|date=November 2018 |bot=InternetArchiveBot |fix-attempted=yes }}
86. ^¹{{cite web|title=btrfsck |url=https://btrfs.wiki.kernel.org/index.php/Btrfsck}}
87. ^¹{{Cite conference |last=Rodeh |first=Ohad |title=B-trees, shadowing, and clones |conference=USENIX Linux Storage & Filesystem Workshop |year=2007 |url=https://www.usenix.org/legacy/events/lsf07/tech/rodeh.pdf}} Also {{Cite journal |last=Rodeh |first=Ohad |year=2008 |title=B-trees, shadowing, and clones |journal=ACM Transactions on Storage}}
88. ^¹²³⁴⁵{{cite web | url = http://btrfs.wiki.kernel.org/articles/b/t/r/Btrfs_design.html | first = Chris |last=Mason | work = Btrfs wiki | accessdate = 8 November 2011 | title = Btrfs design }}
89. ^¹{{cite web | title = Hard Link Limitation | date = 8 August 2010 | accessdate = 2011-11-14 | work = kerneltrap.org | url = http://kerneltrap.org/mailarchive/linux-btrfs/2010/8/2/6885208/thread }}
90. ^¹²{{cite web | url = http://www.oracle.com/technetwork/articles/servers-storage-admin/advanced-btrfs-1734952.html | title = How I Use the Advanced Capabilities of Btrfs | date = August 2012 | accessdate = 2013-09-20 | first1 = Margaret | last1 = Bierman | first2 = Lenz | last2 = Grimmer}}

词条	Btrfs
释义	History Features Implemented Implemented but not recommended for production use Planned but not yet implemented^[35] Cloning Subvolumes and snapshots Send–receive Quota groups In-place conversion from ext2/3/4 and reiserfs Union mounting / seed devices Encryption Checking and recovery Design Root tree File system tree Extents Extent allocation tree Checksum tree and scrubbing Log tree Chunk and device trees Relocation trees Superblock See also Notes References External links {{Use dmy dates\|date=October 2012}}{{Infobox filesystem \| full_name = Btrfs \| name = Btrfs \| license = GNU GPL \| developer = Facebook, Fujitsu, Fusion-IO, Intel, Linux Foundation, Netgear, Oracle Corporation, Red Hat, STRATO AG, and SUSE^[1] \| introduction_os = \| introduction_date = Linux kernel 2.6.29, March 2009 \| partition_id = \| directory_struct = B-tree \| file_struct = Extents \| bad_blocks_struct = \| max_filename_size = 255 ASCII characters (fewer for multibyte character encodings such as Unicode) \| max_files_no = 2⁶⁴^[2]{{Efn\|name="maximum-files"}} \| max_volume_size = 16 EiB{{Efn\|name="kernel-limits"}} \| max_file_size = 16 EiB{{Efn\|name="kernel-limits"}} \| filename_character_set = All except `'/'` and `NUL` (`'\\0'`) \| dates_recorded = Creation (otime),^[2] modification (mtime), attribute modification (ctime), and access (atime) \| date_range = 64 bit signed int offset from 1970-01-01T00:00:00Z^[3] \| date_resolution = Nanosecond \| forks_streams = \| attributes = POSIX and extended attributes \| file_system_permissions = POSIX and ACL \| compression = Yes (zlib, LZO^[4] and (since 4.14) ZSTD^[5]) \| encryption = Planned^[9] \| single_instance_storage = Yes^[6] \| copy_on_write = Yes \| OS = Linux, ReactOS^[7] \| website = {{URL\|https://btrfs.wiki.kernel.org/}} }}Btrfs (pronounced as "butter fuss",^[8] "better F S",^[9] "butter F S",^[9] "b-tree F S",^[10] or simply by spelling it out) is a file system based on the copy-on-write (COW) principle, initially designed at Oracle Corporation for use in Linux. The development of Btrfs began in 2007, and since November 2013 the file system's on-disk format has been marked as stable.^[11] Btrfs is intended to address the lack of pooling, snapshots, checksums, and integral multi-device spanning in Linux file systems.^[9] Chris Mason, the principal Btrfs author, has stated that its goal was "to let Linux scale for the storage that will be available. Scaling is not just about addressing the storage but also means being able to administer and to manage it with a clean interface that lets people see what's being used and makes it more reliable".^[12] History The core data structure of Btrfs{{mdashb}}the copy-on-write B-tree{{mdashb}}was originally proposed by IBM researcher Ohad Rodeh at a presentation at USENIX 2007.{{r\|rodeh-1}} Chris Mason, an engineer working on ReiserFS for SUSE at the time, joined Oracle later that year and began work on a new file system based on these B-trees.{{r\|joinfb}} In 2008, the principal developer of the ext3 and ext4 file systems, Theodore Ts'o, stated that although ext4 has improved features, it is not a major advance; it uses old technology and is a stop-gap. Ts'o said that Btrfs is the better direction because "it offers improvements in scalability, reliability, and ease of management".^[13] Btrfs also has "a number of the same design ideas that reiser3/4 had".^[14] Btrfs 1.0, with finalized on-disk format, was originally slated for a late-2008 release,^[15] and was finally accepted into the Linux kernel mainline in 2009.^[16] Several Linux distributions began offering Btrfs as an experimental choice of root file system during installation.^[17]^[18]^[19] In July 2011, Btrfs automatic defragmentation and scrubbing features were merged into version 3.0 of the Linux kernel mainline.^[26] Besides Mason at Oracle, Miao Xie at Fujitsu contributed performance improvements.^[20] In June 2012, Chris Mason left Oracle for Fusion-io, which he left a year later with Josef Bacik to join Facebook; while at both companies, Mason continued his work on Btrfs.^[21]^[29] In summer 2012, several Linux distributions moved Btrfs from experimental to production or supported status.^[22]^[23] In 2015, Btrfs was adopted as the default filesystem for SUSE Linux Enterprise Server 12.^[24] In August 2017, the release notes of Red Hat Enterprise Linux 7.4 indicated that Red Hat was going to stop supporting Btrfs; RHEL 7.4 includes updates for Btrfs from upstream, but there are no further updates planned to be included, and Btrfs will be removed from Red Hat Enterprise Linux in a future major release.^[25] Suse reaffirmed its commitment to Btrfs.^[26] Features Implemented As of version 4.12 of the Linux kernel, Btrfs implements the following features:^[35]^[27] Mostly self-healing in some configurations due to the nature of copy-on-write Online defragmentation and an autodefrag mount option^[26] Online volume growth and shrinking Online block device addition and removal Online balancing (movement of objects between block devices to balance load) Offline filesystem check^[28] Online data scrubbing for finding errors and automatically fixing them for files with redundant copies RAID 0, RAID 1, and RAID 10^[29] Subvolumes (one or more separately mountable filesystem roots within each disk partition) Transparent compression via zlib, LZO^[30] and (since 4.14) ZSTD,^[31] configurable per file or volume^[32]^[33] Atomic writable (via copy-on-write) or read-only^[34] Snapshots of subvolumes File cloning (copy-on-write on individual files) via `cp --reflink <source file> <destination file>`^[35] Checksums on data and metadata (CRC-32C^[36]) In-place conversion from ext3/4 to Btrfs (with rollback). This feature regressed around btrfs-progs version 4.0, rewritten from scratch in 4.6.^[37] Union mounting of read-only storage, known as file system seeding (read-only storage used as a copy-on-write backing for a writable Btrfs)^[38] Block discard (reclaims space on some virtualized setups and improves wear leveling on SSDs with TRIM) Send/receive (saving diffs between snapshots to a binary stream)^[49] Incremental backup^[39] Out-of-band data deduplication (requires userspace tools)^[40] Implemented but not recommended for production use Hierarchical per-subvolume quotas^[52] RAID 5, RAID 6^[41] Planned but not yet implemented^[35] In-band data deduplication Online filesystem check^[55] RAID with up to six parity devices, surpassing the reliability of RAID 5 and RAID 6^[42] Object-level RAID 0, RAID 1, and RAID 10 Ability to handle swap files and swap partitions^[57] Encryption^[9]^[57] In 2009, Btrfs was expected to offer a feature set comparable to ZFS, developed by Sun Microsystems.^[60] After Oracle's acquisition of Sun in 2009, Mason and Oracle decided to continue with Btrfs development.^[43] Cloning Btrfs provides a clone operation that atomically creates a copy-on-write snapshot of a file. Such cloned files are sometimes referred to as reflinks, in light of the associated Linux kernel system calls.^[44] By cloning, the file system does not create a new link pointing to an existing inode; instead, it creates a new inode that initially shares the same disk blocks with the original file. As a result, cloning works only within the boundaries of the same Btrfs file system, but since version 3.6 of the Linux kernel it may cross the boundaries of subvolumes under certain circumstances.^[63]^[45] The actual data blocks are not duplicated; at the same time, due to the copy-on-write (CoW) nature of Btrfs, modifications to any of the cloned files are not visible in the original file and vice versa.^[65] Cloning should not be confused with hard links, which are directory entries that associate multiple file names with actual files on a file system. While hard links can be taken as different names for the same file, cloning in Btrfs provides independent files that share their disk blocks.^[65]^[46] Support for this Btrfs feature was added in version 7.5 of the GNU coreutils, via the `--reflink` option to the `cp` command.^[47]^[48] Subvolumes and snapshots A Btrfs subvolume can be thought of as a separate POSIX file namespace, mountable separately by passing `subvol` or `subvolid` options to the {{man\|8\|mount\|man.cx\|\|inline}} utility. It can also be accessed by mounting the top-level subvolume, in which case subvolumes are visible and accessible as its subdirectories.^[70] Subvolumes can be created at any place within the file system hierarchy, and they can also be nested. Nested subvolumes appear as subdirectories within their parent subvolumes, similarly to the way a top-level subvolume presents its subvolumes as subdirectories. Deleting a subvolume is not possible until all subvolumes below it in the nesting hierarchy are deleted; as a result, top-level subvolumes cannot be deleted.^[71] Any Btrfs file system always has a default subvolume, which is initially set to be the top-level subvolume, and is mounted by default if no subvolume selection option is passed to `mount`. The default subvolume can be changed as required.^[71] A Btrfs snapshot is a subvolume that shares its data (and metadata) with some other subvolume, using Btrfs' copy-on-write capabilities, and modifications to a snapshot are not visible in the original subvolume. Once a writable snapshot is made, it can be treated as an alternate version of the original file system. For example, to roll back to a snapshot, a modified original subvolume needs to be unmounted and the snapshot needs to be mounted in its place. At that point, the original subvolume may also be deleted.^[70] The copy-on-write (CoW) nature of Btrfs means that snapshots are quickly created, while initially consuming very little disk space. Since a snapshot is a subvolume, creating nested snapshots is also possible. Taking snapshots of a subvolume is not a recursive process; thus, if a snapshot of a subvolume is created, every subvolume or snapshot that the subvolume already contains is mapped to an empty directory of the same name inside the snapshot.^[70]^[71] Taking snapshots of a directory is not possible, as only subvolumes can have snapshots. However, there is a workaround that involves reflinks spread across subvolumes: a new subvolume is created, containing cross-subvolume reflinks to the content of the targeted directory. Having that available, a snapshot of this new volume can be created.^[63] A subvolume in Btrfs is quite different from a traditional Logical Volume Manager (LVM) logical volume. With LVM, a logical volume is a separate block device, while a Btrfs subvolume is not and it cannot be treated or used that way.^[70] Making dd or LVM snapshots of btrfs leads to dataloss if either the original or the copy is mounted while both are on the same computer.^[49] Send–receive Given any pair of subvolumes (or snapshots), Btrfs can generate a binary diff between them (by using the `btrfs send` command) that can be replayed later (by using `btrfs receive`), possibly on a different Btrfs file system. The send–receive feature effectively creates (and applies) a set of data modifications required for converting one subvolume into another.^[49]^[80] The send/receive feature can be used with regularly scheduled snapshots for implementing a simple form of file system master–slave replication, or for the purpose of performing incremental backups.^[49]^[80] Quota groups A quota group (or qgroup) imposes an upper limit to the space a subvolume or snapshot may consume. A new snapshot initially consumes no quota because its data is shared with its parent, but thereafter incurs a charge for new files and copy-on-write operations on existing files. When quotas are active, a quota group is automatically created with each new subvolume or snapshot. These initial quota groups are building blocks which can be grouped (with the `btrfs qgroup` command) into hierarchies to implement quota pools.^[52] Quota groups only apply to subvolumes and snapshots, while having quotas enforced on individual subdirectories, users, or user groups is not possible. However, workarounds are possible by using different subvolumes for all users or user groups that require a quota to be enforced. In-place conversion from ext2/3/4 and reiserfs As the result of having very little metadata anchored in fixed locations, Btrfs can warp to fit unusual spatial layouts of the backend storage devices. The `btrfs-convert` tool exploits this ability to do an in-place conversion of an ext2/3/4 or ReiserFS file system, by nesting the equivalent Btrfs metadata in its unallocated space—while preserving an unmodified copy of the original file system.^[84] The conversion involves creating a copy of the whole ext2/3/4 metadata, while the Btrfs files simply point to the same blocks used by the ext2/3/4 files. This makes the bulk of the blocks shared between the two filesystems before the conversion becomes permanent. Thanks to the copy-on-write nature of Btrfs, the original versions of the file data blocks are preserved during all file modifications. Until the conversion becomes permanent, only the blocks that were marked as free in ext2/3/4 are used to hold new Btrfs modifications, meaning that the conversion can be undone at any time (although doing so will erase any changes made after the conversion to Btrfs).^[84] All converted files are available and writable in the default subvolume of the Btrfs. A sparse file holding all of the references to the original ext2/3/4 filesystem is created in a separate subvolume, which is mountable on its own as a read-only disk image, allowing both original and converted file systems to be accessed at the same time. Deleting this sparse file frees up the space and makes the conversion permanent.^[84] As of June 2015 and 4.x versions of the Linux kernel mainline, the in-place ext3/4 conversion was considered untested and rarely used.^[84] The feature, however, was rewritten from scratch in 2016 for `btrfs-progs` 4.6.^[37] and is considered stable since then. In-place conversion from ReiserFS was introduced in September 2017 with kernel 4.13.^[50] Union mounting / seed devices When creating a new Btrfs, an existing Btrfs can be used as a read-only "seed" file system.^[51] The new file system will then act as a copy-on-write overlay on the seed, as a form of union mounting. The seed can be later detached from the Btrfs, at which point the rebalancer will simply copy over any seed data still referenced by the new file system before detaching. Mason has suggested this may be useful for a Live CD installer, which might boot from a read-only Btrfs seed on an optical disc, rebalance itself to the target partition on the install disk in the background while the user continues to work, then eject the disc to complete the installation without rebooting.^[91] Encryption In his 2009 interview, Chris Mason stated that support for encryption was planned for Btrfs.^[52] In the meantime, a workaround for combining encryption with Btrfs is to use a full-disk encryption mechanism such as dm-crypt / LUKS on the underlying devices and to create the Btrfs filesystem on top of that layer. Checking and recovery {{Update\|section\|date=November 2016\|inaccurate=yes}} Unix systems traditionally rely on "fsck" programs to check and repair filesystems. This functionality is implemented via the `btrfs check` program. Since version 4.0 this functionality is deemed relatively stable. However, as of August 2017, the btrfs documentation suggests that it be used only after having tried other recovery methods.^[93] There is another tool, named `btrfs-restore`, that can be used to recover files from an unmountable filesystem, without modifying the broken filesystem itself (i.e., non-destructively).^[53] In normal use, Btrfs is mostly self-healing and can recover from broken root trees at mount time, thanks to making periodic data flushes to permanent storage, by default every 30 seconds. Thus, isolated errors will cause a maximum of 30 seconds of filesystem changes to be lost at the next mount.^[54] This period can be changed by specifying a desired value (in seconds) for the `commit` mount option.^[55]^[56] Design Ohad Rodeh's original proposal at USENIX 2007 noted that B+ trees, which are widely used as on-disk data structures for databases, could not efficiently allow copy-on-write-based snapshots because its leaf nodes were linked together: if a leaf was copy-on-written, its siblings and parents would have to be as well, as would their siblings and parents and so on until the entire tree was copied. He suggested instead a modified B-tree (which has no leaf linkage), with a refcount associated to each tree node but stored in an ad-hoc free map structure and certain relaxations to the tree's balancing algorithms to make them copy-on-write friendly. The result would be a data structure suitable for a high-performance object store that could perform copy-on-write snapshots, while maintaining good concurrency.^[98] At Oracle later that year, Chris Mason began work on a snapshot-capable file system that would use this data structure almost exclusively—not just for metadata and file data, but also recursively to track space allocation of the trees themselves. This allowed all traversal and modifications to be funneled through a single code path, against which features such as copy-on-write, checksumming and mirroring needed to be implemented only once to benefit the entire file system.^[60] Btrfs is structured as several layers of such trees, all using the same B-tree implementation. The trees store generic items sorted on a 136-bit key. The first 64 bits of the key are a unique object id. The middle 8 bits are an item type field; its use is hardwired into code as an item filter in tree lookups. Objects can have multiple items of multiple types. The remaining right-hand 64 bits are used in type-specific ways. Therefore, items for the same object end up adjacent to each other in the tree, ordered by type. By choosing certain right-hand key values, objects can further put items of the same type in a particular order.^[60]^[2] Interior tree nodes are simply flat lists of key-pointer pairs, where the pointer is the logical block number of a child node. Leaf nodes contain item keys packed into the front of the node and item data packed into the end, with the two growing toward each other as the leaf fills up.^[60] Root tree {{Unreferenced section\|date=January 2017}} Every tree appears as an object in the root tree (or tree of tree roots). Some trees, such as file system trees and log trees, have a variable number of instances, each of which is given its own object id. Trees which are singletons (the data relocation, extent and chunk trees) are assigned special, fixed object ids ≤256. The root tree appears in itself as a tree with object id 1. Trees refer to each other by object id. They may also refer to individual nodes in other trees as a triplet of the tree's object id, the node's level within the tree and its leftmost key value. Such references are independent of where the tree is actually stored. File system tree User-visible files and directories are contained in a file system tree. There is one file system tree per subvolume. Subvolumes can nest, in which case they appear as a directory item (described below) whose data is a reference to the nested subvolume's file system tree.{{Citation needed\|date=January 2017}} Within the file system tree, each file and directory object has an inode item. Extended attributes and ACL entries are stored alongside in separate items.{{Citation needed\|date=January 2017}} Within each directory, directory entries appear as directory items, whose right-hand key values are a CRC32C hash of their filename. Their data is a location key, or the key of the inode item it points to. Directory items together can thus act as an index for path-to-inode lookups, but are not used for iteration because they are sorted by their hash, effectively randomly permuting them. This means user applications iterating over and opening files in a large directory would thus generate many more disk seeks between non-adjacent files—a notable performance drain in other file systems with hash-ordered directories such as ReiserFS,^[57] ext3 (with Htree-indexes enabled^[58]) and ext4, all of which have TEA-hashed filenames. To avoid this, each directory entry has a directory index item, whose right-hand key value of the item is set to a per-directory counter that increments with each new directory entry. Iteration over these index items thus returns entries in roughly the same order as they are stored on disk. Besides inode items, files and directories also have a reference item whose right-hand key value is the object id of their parent directory. The data part of the reference item is the filename that inode is known by in that directory. This allows upward traversal through the directory hierarchy by providing a way to map inodes back to paths.{{Citation needed\|date=January 2017}} Files with hard links in multiple directories have multiple reference items, one for each parent directory. Files with multiple hard links in the same directory pack all of the links' filenames into the same reference item. This was a design flaw that limited the number of same-directory hard links to however many could fit in a single tree block. (On the default block size of 4 KiB, an average filename length of 8 bytes and a per-filename header of 4 bytes, this would be less than 350.) Applications which made heavy use of multiple same-directory hard links, such as git, GNUS, GMame and BackupPC were later observed to fail after hitting this limit.^[105] The limit was eventually removed^[59] (and as of October 2012 has been merged^[60] pending release in Linux 3.7) by introducing spillover extended reference items to hold hard link filenames which could not otherwise fit. Extents {{Refimprove section\|date=January 2017}} File data is kept outside the tree in extents, which are contiguous runs of disk blocks. Extent blocks default to 4KiB in size, do not have headers and contain only (possibly compressed) file data. In compressed extents, individual blocks are not compressed separately; rather, the compression stream spans the entire extent. Files have extent data items to track the extents which hold their contents. The item's right-hand key value is the starting byte offset of the extent. This makes for efficient seeks in large files with many extents, because the correct extent for any given file offset can be computed with just one tree lookup. Snapshots and cloned files share extents. When a small part of a large such extent is overwritten, the resulting copy-on-write may create three new extents: a small one containing the overwritten data, and two large ones with unmodified data on either side of the overwrite. To avoid having to re-write unmodified data, the copy-on-write may instead create bookend extents, or extents which are simply slices of existing extents. Extent data items allow for this by including an offset into the extent they are tracking: items for bookends are those with non-zero offsets.^[2] If the file data is small enough to fit inside a tree node, it is instead pulled in-tree and stored inline in the extent data item. Each tree node is stored in its own tree block—a single uncompressed block with a header. The tree block is regarded as a free-standing, single-block extent. Extent allocation tree {{Refimprove section\|date=January 2017}} The extent allocation tree acts as an allocation map for the file system. Unlike other trees, items in this tree do not have object ids and represent regions of space: their left-hand and right-hand key values are the starting offsets and lengths of the regions they represent. The file system zones its allocated space into block groups, which are variable-sized allocation regions that alternate successively between preferring metadata extents (tree nodes) and data extents (file contents). The default ratio of data to metadata block groups is 1:2. They are intended to work like the Orlov block allocator and block groups in ext3 in allocating related files together and resisting fragmentation by leaving allocation gaps between groups. (ext3 block groups, however, have fixed locations computed from the size of the file system, whereas those in Btrfs are dynamic and are created as needed.) Each block group is associated with a block group item. Inode items in the file system tree include a reference to their current block group.^[2] Extent items contain a back-reference to the tree node or file occupying that extent. There may be multiple back-references if the extent is shared between snapshots. If there are too many back-references to fit in the item, they spill out into individual extent data reference items. Tree nodes, in turn, have back-references to their containing trees. This makes it possible to find which extents or tree nodes are in any region of space by doing a B-tree range lookup on a pair of offsets bracketing that region, then following the back-references. For relocating data, this allows an efficient upwards traversal from the relocated blocks to quickly find and fix all downwards references to those blocks, without having to walk the entire file system. This, in turn, allows the file system to efficiently shrink, migrate and defragment its storage online. The extent allocation tree, as with all other trees in the file system, is copy-on-write. Writes to the file system may thus cause a cascade whereby changed tree nodes and file data result in new extents being allocated, causing the extent tree to itself change. To avoid creating a feedback loop, extent tree nodes which are still in memory but not yet committed to disk may be updated in-place to reflect new copy-on-written extents. In theory, the extent allocation tree makes a conventional free-space bitmap unnecessary because the extent allocation tree acts as a B-tree version of a BSP tree. In practice, however, an in-memory red-black tree of page-sized bitmaps is used to speed up allocations. These bitmaps are persisted to disk (starting in Linux 2.6.37, via the `space_cache` mount option^[61]) as special extents that are exempt from checksumming and copy-on-write. The extent items tracking these extents are stored in the root tree. Checksum tree and scrubbing {{See also\|Silent data corruption}}CRC-32C checksums are computed for both data and metadata and stored as checksum items in a checksum tree. There is room for 256 bits of metadata checksums and up to a full leaf block (roughly 4 KB or more) for data checksums. More checksum algorithm options are planned for the future.^[35]^[62] There is one checksum item per contiguous run of allocated blocks, with per-block checksums packed end-to-end into the item data. If there are more checksums than can fit, they spill rightwards over into another checksum item in a new leaf. If the file system detects a checksum mismatch while reading a block, it first tries to obtain (or create) a good copy of this block from another device{{spaced ndash}} if internal mirroring or RAID techniques are in use.^[113]^[63] Btrfs can initiate an online check of the entire file system by triggering a file system scrub job that is performed in the background. The scrub job scans the entire file system for integrity and automatically attempts to report and repair any bad blocks it finds along the way.^[113]^[64] Log tree An fsync is a request to commit modified data immediately to stable storage. fsync-heavy workloads (like a database or a virtual machine whose running OS fsyncs intensively) could potentially generate a great deal of redundant write I/O by forcing the file system to repeatedly copy-on-write and flush frequently modified parts of trees to storage. To avoid this, a temporary per-subvolume log tree is created to journal fsync-triggered copy-on-writes. Log trees are self-contained, tracking their own extents and keeping their own checksum items. Their items are replayed and deleted at the next full tree commit or (if there was a system crash) at the next remount. Chunk and device trees {{Unreferenced section\|date=January 2017}} Block devices are divided into physical chunks of 256 MB or more. Physical chunks across multiple devices can be mirrored or striped together into a single logical chunk. These logical chunks are combined into a single logical address space that the rest of the filesystem uses. The chunk tree tracks this by storing each device therein as a device item and logical chunks as chunk map items, which provide a forward mapping from logical to physical addresses by storing their offsets in the right-hand 64 bits of their key. Chunk map items can be one of several different types: single 1 logical to 1 physical chunk dup 1 logical chunk to 2 physical chunks on 1 block device raid0 N logical chunks to N≥2 physical chunks across N≥2 block devices raid1 1 logical chunk to N≥2 physical chunks across N≥2 block devices raid5 N-1 logical chunks to N≥3 physical chunks across N≥3 block devices, with 1 physical chunk used as parity raid6 N-2 logical chunks to N≥4 physical chunks across N≥4 block devices, with 2 physical chunks used as parity N is however many block devices still have free space when the chunk is allocated. If N is not large enough for the chosen mirroring/mapping, then the filesystem is effectively out of space. The device tree is the inverse of the chunk tree, and has device extent items which provide a reverse mapping from byte-ranges of block devices back to logical chunks by storing the device number in the left hand 64-bits and physical offset in the right-hand 64 bits of they key. These two trees together allow Btrfs to grow, shrink and even change RAID levels without unmounting because they make it possible to efficiently locate the chunks affected by shrink/move operations and then relocate their contents on-the-fly. The file system, chunks and devices are all assigned a Universally Unique Identifier (UUID). The header of every tree node contains both the UUID of its containing chunk and the UUID of the file system. The chunk and device trees refer to devices and chunks with UUIDs. On filesystems with just a single block device, "dup" is also the default profile for metadata. All this is intended to improve the odds of successful data salvage in the event of media errors). Relocation trees Defragmentation, shrinking and rebalancing operations require extents to be relocated. However, doing a simple copy-on-write of the relocating extent will break sharing between snapshots and consume disk space. To preserve sharing, an update-and-swap algorithm is used, with a special relocation tree serving as scratch space for affected metadata. The extent to be relocated is first copied to its destination. Then, by following backreferences upward through the affected subvolume's file system tree, metadata pointing to the old extent is progressively updated to point at the new one; any newly updated items are stored in the relocation tree. Once the update is complete, items in the relocation tree are swapped with their counterparts in the affected subvolume, and the relocation tree is discarded.^[65] Superblock All the file system's trees—including the chunk tree itself—are stored in chunks, creating a potential bootstrapping problem when mounting the file system. To bootstrap into a mount, a list of physical addresses of chunks belonging to the chunk and root trees must be stored in the superblock.^[66] Superblock mirrors are kept at fixed locations:^[67] 64 KiB into every block device, with additional copies at 64 MiB, 256 GiB and 1 PiB. When a superblock mirror is updated, its generation number is incremented. At mount time, the copy with the highest generation number is used. All superblock mirrors are updated in tandem, except in SSD mode which alternates updates among mirrors to provide some wear levelling. See also {{Portal\|Free and open-source software\|Linux}} Comparison of file systems ZFS APFS, a copy-on-write file system for macOS, iOS, tvOS, watchOS and audioOS HAMMER{{snd}} DragonFly BSD's file system that uses B-trees, paired with checksums as a countermeasure for data corruption ReFS, a copy-on-write file system for Windows Server 2012 List of file systems Notes {{Notelist\|refs={{Efn\|name="kernel-limits"\|This is the Btrfs' own on-disk size limit. The limit is reduced down to 8 EiB on 64-bit systems and 2 EiB on 32-bit systems due to Linux kernel's internal limits, unless kernel's `CONFIG_LBD` configuration option (available since the 2.6.x kernel series) is enabled to remove these kernel limits.^[68]^[69]}}{{Efn\|name="maximum-files"\|Every item in Btrfs has a 64-bit identifier, which means the most files one can have on a Btrfs filesystem is 2⁶⁴.^[2]}} }} References 1. ^{{cite web \|url=https://btrfs.wiki.kernel.org/index.php/Contributors \|title=Btrfs Contributors at kernel.org \|date=2016-01-18\| publisher=kernel.org \|accessdate=2016-01-20}} 2. ^{{cite web \| url = https://lwn.net/Articles/397442/ \| title = File creation times \| date = 2010-07-26 \| accessdate = 2015-08-15 \| author = Jonathan Corbet \| publisher = LWN.net}} 3. ^https://btrfs.wiki.kernel.org/index.php/On-disk_Format#Basic_Structures 4. ^{{cite web\|url=https://btrfs.wiki.kernel.org\|title=btrfs Wiki\|work=kernel.org\|accessdate=19 April 2015}} 5. ^https://kernelnewbies.org/Linux_4.14 6. ^{{cite web\|url=https://btrfs.wiki.kernel.org/index.php/Deduplication\|title=Deduplication\|work=kernel.org\|accessdate=19 April 2015}} 7. ^{{cite web\|url=https://reactos.org/project-news/reactos-041-released\|title=ReactOS 0.4.1 Released\|work=reactos.org\|accessdate=11 August 2016}} 8. ^http://streaming.oracle.com/ebn/podcasts/media/20209545_Oracle-Linux-7.mp4 9. ^{{ cite video \| first = Valerie \|last=Henson \| title = Chunkfs: Fast file system check and repair \| date = 31 January 2008 \| url = http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-262.ogg \| time = 18m 49s \| quote = It's called Butter FS or B-tree FS, but all the cool kids say Butter FS \| location = Melbourne, Australia \| accessdate = 2008-02-05 }} 10. ^{{ cite video \| first = Valerie \|last=Henson \| title = Chunkfs: Fast file system check and repair \| date = 31 January 2008 \| url = http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-262.ogg \| time = 18m 49s \| quote = It's called Butter FS or B-tree FS, but all the cool kids say Butter FS \| location = Melbourne, Australia \| accessdate = 2008-02-05 }} 11. ^{{cite web \|title = Linux kernel commit changing stability status in fs/btrfs/Kconfig \| url = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4204617d142c0887e45fda2562cb5c58097b918e \| accessdate = 2019-02-08 }} 12. ^{{cite web \|title=A Better File System for Linux? \|first=Sean Michael \|last=Kerner \|date=30 October 2008 \|accessdate=30 October 2008 \|work=InternetNews.com \|url=http://www.internetnews.com/dev-news/article.php/3781676/A+Better+File+System+for+Linux.htm \|archiveurl=https://www.webcitation.org/68elQlAN4?url=http://www.internetnews.com/dev-news/article.php/3781676/A%20Better%20File%20System%20for%20Linux.htm \|archivedate=24 June 2012 \|deadurl=no \|df=dmy }} 13. ^{{ cite journal \|url=https://arstechnica.com/open-source/news/2009/04/linux-collaboration-summit-the-kernel-panel.ars \|title=Panelists ponder the kernel at Linux Collaboration Summit \|first=Ryan \|last=Paul \|date=13 April 2009 \|accessdate=2009-08-22 \|publisher=Ars Technica{{inconsistent citations}} \|archiveurl=https://www.webcitation.org/68elXKsj7?url=http://arstechnica.com/information-technology/2009/04/linux-collaboration-summit-the-kernel-panel/ \|archivedate=24 June 2012 \|deadurl=yes \|df=dmy }} 14. ^{{ cite mailing list \| title = Re: reiser4 for 2.6.27-rc1 \| first = Theodore \|last=Ts'o \| url = https://lkml.org/lkml/2008/8/1/217 \| date = 1 August 2008 \| accessdate = 2010-12-31 \| mailinglist = linux-kernel }} 15. ^{{cite web \| url = http://btrfs.wiki.kernel.org/index.php/Development_timeline \|deadurl= yes \| title = Development timeline \| work= Btrfs wiki \| date = 11 December 2008 \| accessdate = 5 November 2011 \| archivedate= 20 December 2008 \|archiveurl= https://web.archive.org/web/20081220083235/http://btrfs.wiki.kernel.org/index.php/Development_timeline }} 16. ^{{ cite news \| url = http://www.linux-magazine.com/Online/News/Kernel-2.6.29-Corbet-Says-Btrfs-Next-Generation-Filesystem \| title = Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem \|first= Britta \|last=Wuelfing \|work= Linux Magazine \| date = 12 January 2009 \| accessdate= 5 November 2011 }} 17. ^{{cite web \|title=Red Hat Enterprise Linux 6 documentation: Technology Previews \|url=http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html#id4452791 \|access-date=21 January 2011 \|archive-url=https://web.archive.org/web/20110528160211/http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html#id4452791#id4452791 \|archive-date=28 May 2011 \|dead-url=yes \|df=dmy-all }} 18. ^{{cite web \|title=Fedora Weekly News Issue 276 \|url=http://fedoraproject.org/wiki/FWN/LatestIssue#What.27s_new_in_Fedora_15_.28Lovelock.29.3F \|date=25 May 2011}} 19. ^{{ cite press release \| url=http://www.debian.org/News/2011/20110205a.en.html \| title=Debian 6.0 "Squeeze" released \| date=6 February 2011 \| publisher=Debian \| quote=Support has also been added for the ext4 and Btrfs filesystems... \| accessdate=2011-02-08}} 20. ^{{ cite news \|title= Kernel Log: Coming in 3.0 (Part 2) - Filesystems \|first=Thorsten \|last=Leemhuis \|work= The H Open \|date= 21 June 2011 \|url= http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-0-Part-2-Filesystems-1263681.html \|accessdate= 8 November 2011 }} 21. ^{{cite web \|url=http://www.itwire.com/business-it-news/open-source/62417-faecbook-lures-top-btrfs-hackers\|title=iTWire\|author=Sam Varghese\|work=itwire.com\|accessdate=19 April 2015}} 22. ^{{cite web\|url=http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11-SP2/#fate-306585\|title=SLES 11 SP2 Release Notes\|date=21 August 2012\|accessdate=2012-08-29}} 23. ^{{cite web\|url=http://www.oracle.com/us/technologies/linux/025994.htm\|title=Oracle Linux Technical Information\|accessdate=2012-11-14}} 24. ^{{cite web\|url=https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221\|title=SUSE Linux Enterprise Server 12 Release Notes\|date=2015-11-05\|accessdate=2016-01-20}} 25. ^{{cite web\|url=https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html\|title=Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality\|date=2017-08-01\|accessdate=2017-08-15}} 26. ^{{cite web\|url=https://www.suse.com/communities/blog/butter-bei-die-fische/\|title=Butter bei die Fische!\|author=mge1512\|website=suse.com\|date=2017-08-23\|accessdate=2017-08-24}} 27. ^{{cite web \|title = Btrfs Wiki: Changelog \|date=2013-11-08 \|accessdate=2013-11-27 \|url=https://btrfs.wiki.kernel.org/index.php/Changelog \|website=btrfs.wiki.kernel.org}} 28. ^{{cite web \| url=https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-check \| title=Manpage btrfs-check}} 29. ^{{cite web \| url = https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices \| title = Using Btrfs with Multiple Devices \| date = 2013-11-07 \| accessdate = 2013-11-20 \| website = kernel.org}} 30. ^{{cite web\|url=https://btrfs.wiki.kernel.org\|title=btrfs Wiki\|work=kernel.org\|accessdate=19 April 2015}} 31. ^https://kernelnewbies.org/Linux_4.14 32. ^{{cite web \| url = https://btrfs.wiki.kernel.org/index.php/Compression \| title = Compression \| date = 2013-06-25 \| accessdate = 2014-04-01 \| website = kernel.org}} 33. ^{{cite web \| url = https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=63541927c8d11d2686778b1e8ec71c14b4fd53e4 \| title = Btrfs: add support for inode properties \| date = 2014-01-28 \| accessdate = 2014-04-01 \| website = kernel.org}} 34. ^{{cite web \| url = https://lwn.net/Articles/417617/ \| title= btrfs: Readonly snapshots \| accessdate = 2011-12-12 }} 35. ^{{cite web \| url = https://blogs.oracle.com/otn/save-disk-space-on-linux-by-cloning-files-on-btrfs-and-ocfs2 \| title= Save disk space on Linux by cloning files on Btrfs and OCFS2 \| accessdate = 2017-08-01 }} 36. ^{{cite web \| url = http://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_function_does_Btrfs_use.3F \| work = Btrfs wiki \| title = Wiki FAQ: What checksum function does Btrfs use? \| accessdate = 2009-06-15 }} 37. ^¹{{cite web \| url = https://www.spinics.net/lists/linux-btrfs/msg56040.html \| title = Btrfs progs release 4.6 \| accessdate = 2017-08-01 }} 38. ^{{cite web \| title = Btrfs changelog \| first = Chris \| last = Mason \| date = 12 January 2009 \| accessdate = 2012-02-12 \| url = http://btrfs.ipv5.de/index.php?title=Changelog#Seed_Device_support }} 39. ^{{cite web\|title = Btrfs Wiki: Incremental Backup\|date = 2013-05-27\|accessdate = 2013-11-27\|url = https://btrfs.wiki.kernel.org/index.php/Incremental_Backup}} 40. ^{{cite web\|title = Btrfs Wiki: Deduplication\|date = 2013-09-13\|accessdate = 2013-11-27\|url = https://btrfs.wiki.kernel.org/index.php/Deduplication}} 41. ^{{cite web \| url = https://btrfs.wiki.kernel.org/index.php/RAID56 \| title = RAID 5/6 \| date = 2016-07-16 \| accessdate = 2016-10-01 \| author = btrfs \| publisher = kernel.org}} 42. ^{{cite web \| title=btrfs: lib: raid: New RAID library supporting up to six parities \| url=https://lwn.net/Articles/579034/ \| first=Andrea \| last=Mazzoleni \| accessdate=2014-03-16}} 43. ^{{ cite news \|date= 22 April 2009 \|first=Marcel \|last=Hilzinger \|title=Future of Btrfs Secured \|publisher=Linux Magazine \|url=http://www.linux-magazine.com/Online/News/Future-of-Btrfs-Secured \|accessdate = 5 November 2011}} 44. ^{{cite web \| url = https://lwn.net/Articles/331808/ \| title = The two sides of reflink() \| date = 2009-05-05 \| accessdate = 2013-10-17 \| author = Jonathan Corbet \| publisher = LWN.net}} 45. ^{{cite web \| url = https://github.com/torvalds/linux/commit/362a20c5e27614739c46707d1c5f55c214d164ce \| title = btrfs: allow cross-subvolume file clone \| accessdate = 2013-11-04 \| website = github.com}} 46. ^{{cite web \| url = http://www.pixelbeat.org/docs/unix_links.html \| title = Symlinks reference names, hardlinks reference meta-data and reflinks reference data \| date = 2010-10-27 \| accessdate = 2013-10-17 \| website = pixelbeat.org}} 47. ^{{cite web \| url = http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=NEWS;h=601d73251c49ce36b39f9838aa818c740cf3a10a;hb=af1996dde2d0089117a9e5e7aa543c6e55474b77 \| title = GNU coreutils NEWS: Noteworthy changes in release 7.5 \| first = Jim \| last = Meyering \| date = 20 August 2009 \| accessdate = 2009-08-30 \| website = savannah.gnu.org}} 48. ^{{cite web \| url = http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=a1d7469835371ded0ad8e3496bc5a5bebf94ccef \| title = cp: accept the --reflink option \| first = Giuseppe \| last = Scrivano \| date = 1 August 2009 \| accessdate = 2009-11-02 \| website = savannah.gnu.org}} 49. ^https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices 50. ^{{cite web \| url = https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-convert \| title = btrfs-convert(8) manual page \| accessdate = 2018-04-24 }} 51. ^{{cite web \| url=https://btrfs.wiki.kernel.org/index.php/Seed-device \| title=Seed device }} 52. ^{{cite web \| url = http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux \| title = A Conversation with Chris Mason on BTRfs: the next generation file system for Linux \| date = 2009-06-22 \| accessdate = 2014-10-09 \| author = Amanda McPherson \| publisher = Linux Foundation \| quote = In future releases we plan to add online fsck, deduplication, encryption and other features that have been on admin wish lists for a long time. \| deadurl = yes \| archiveurl = https://www.webcitation.org/68ektBKkv?url=http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux \| archivedate = 24 June 2012 \| df = dmy-all }} 53. ^{{cite web\|title=Restore \|url=https://btrfs.wiki.kernel.org/index.php/Restore}} 54. ^{{cite web\|url=https://btrfs.wiki.kernel.org/index.php/Problem_FAQ \|title=Problem FAQ - btrfs Wiki \|website=kernel.org \|date=2013-07-31 \|accessdate=2014-01-16}} 55. ^{{cite web \| url = https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=906c176e541f89ed3c04d0e9af1c7cf7b3cc1adb \| title = kernel/git/torvalds/linux.git: Documentation: filesystems: add new btrfs mount options (Linux kernel source tree) \| date = 2013-11-21 \| accessdate = 2014-02-06 \| publisher = kernel.org}} 56. ^{{cite web\|url=https://btrfs.wiki.kernel.org/index.php/Mount_options \|title=Mount options - btrfs Wiki \| website=kernel.org \|date=2013-11-12 \|accessdate=2014-01-16}} 57. ^{{cite web\|url = http://lkml.indiana.edu/hypermail/linux/kernel/0112.0/2019.html\|title = Re: Ext2 directory index: ALS paper and benchmarks\|work = ReiserFS developers mailing list\|first = Hans\|last = Reiser\|date = 2001-12-07\|accessdate = 2009-08-28}} 58. ^{{cite web\|url = http://oss.oracle.com/~mason/acp/ \|first=Chris \|last=Mason \|title = Acp\|work = Oracle personal web page\|accessdate = 2011-11-05}} 59. ^{{citation\|title = btrfs: extended inode refs\|first = Mark\|last = Fasheh\|date = 2012-10-09\|accessdate = 2012-11-07\|url = https://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298\|archive-url = https://archive.is/20130415062145/http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298\|dead-url = yes\|archive-date = 2013-04-15}} 60. ^{{citation\|title = Pull btrfs update from Chris Mason\|first = Linus\|last = Torvalds\|date = 2012-10-10\|accessdate = 2012-11-07\|url = https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5\|archive-url = https://archive.is/20130415043758/http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5\|dead-url = yes\|archive-date = 2013-04-15\|work = git.kernel.org}} 61. ^{{cite web\| title = Benchmarks Of The Btrfs Space Cache Option\|accessdate = 2012-11-16\|date = 2010-12-24\|first = Michael\|last = Larabel\|url = https://www.phoronix.com/scan.php?page=article&item=btrfs_space_cache&num=1\|publisher = Phoronix}} 62. ^{{cite web \| url = https://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_function_does_Btrfs_use.3F \| title = FAQ - btrfs Wiki: What checksum function does Btrfs use? \| accessdate = 2013-09-19 \| publisher = The btrfs Project}} 63. ^{{cite web\|last=Salter\|first=Jim\|title=Bitrot and atomic COWs: Inside "next-gen" filesystems\|url=https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/\|publisher=Ars Technica\|accessdate=15 January 2014\|date=15 January 2014}} 64. ^{{cite web \| url = https://blogs.oracle.com/wim/entry/btrfs_scrub_go_fix_corruptions \| title = btrfs scrub - go fix corruptions with mirror copies please! \| date = 2011-09-28 \| accessdate = 2013-09-20 \| first = Wim \| last = Coekaerts}} 65. ^{{citation\|title = BTRFS: The Linux B-tree Filesystem\|date = 2012-07-09\|first1 = Chris\|last1 = Mason\|first2 = Ohad\|last2 = Rodeh\|first3 = Josef\|last3 = Bacik\|publisher = IBM Research\|url = http://domino.watson.ibm.com/library/CyberDig.nsf/papers/6E1C5B6A1B6EDD9885257A38006B6130/$File/rj10501.pdf\|accessdate = 2012-11-12}} 66. ^{{cite web \| url = http://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support \|deadurl= yes \| first= Chris \|last=Mason \| work = Btrfs wiki \| accessdate = 5 November 2011 \| date = 30 April 2008 \|title = Multiple device support \| archivedate= 20 July 2011 \|archiveurl= https://web.archive.org/web/20110720220543/https://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support }} 67. ^{{cite mailing list\|url = http://kerneltrap.org/mailarchive/linux-btrfs/2010/4/20/6884623\|title = Re: Restoring BTRFS partition\|mailinglist = linux-btrfs\|date = 2010-04-20\|last = Bartell\|first = Sean}} 68. ^{{cite web \| url = http://users.suse.com/~aj/linux_lfs.html \| title = Large File Support in Linux \| date = 2005-02-15 \| accessdate = 2015-08-12 \| author = Andreas Jaeger \| website = users.suse.com}} 69. ^{{cite web \|url = http://kernel.xc.net/html/linux-2.6.29/x86/LBD \|title = Linux kernel configuration help for CONFIG_LBD in 2.6.29 on x86 \|accessdate = 2015-08-12 \|website = kernel.xc.net \|archive-url = https://web.archive.org/web/20150906090823/http://kernel.xc.net/html/linux-2.6.29/x86/LBD# \|archive-date = 6 September 2015 \|dead-url = yes \|df = dmy-all}} 70. ^¹²³⁴{{cite web \|title=A Conversation with Chris Mason on BTRfs: the next generation file system for Linux \|first=Amanda \|last=McPherson \|date=22 June 2009 \|accessdate=2009-09-01 \|publisher=Linux Foundation \|url=http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux \|archiveurl=https://www.webcitation.org/68ektBKkv?url=http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux \|archivedate=24 June 2012 \|deadurl=yes \|df=dmy }} 71. ^¹²{{cite web \| url = http://kernelnewbies.org/Linux_3.0#head-3e596e03408e1d32a7cc381d6f54e87feee22ee4 \| title = Linux kernel 3.0, Section 1.1. Btrfs: Automatic defragmentation, scrubbing, performance improvements \| date = 2011-07-21 \| accessdate = 2016-04-05 \| website = kernelnewbies.org}} 72. ^¹{{cite web\|url=https://www.phoronix.com/scan.php?page=news_item&px=MTUzNTE\|title=Lead Btrfs File-System Developers Join Facebook\|work=phoronix.com\|accessdate=19 April 2015}} 73. ^¹²³{{cite web \|title=Btrfs Wiki: Features \|date=2013-11-27 \|accessdate=2013-11-27 \|url=https://btrfs.wiki.kernel.org/index.php/Main_Page#Features \|website=btrfs.wiki.kernel.org}} 74. ^¹²³{{citation\|url = https://lwn.net/Articles/506244/\|first = Jonathan\|last = Corbet\|title = Btrfs send/receive\|publisher = LWN.net\|date = 2012-07-11\|accessdate = 2012-11-14}} 75. ^¹²{{citation\|url = http://sensille.com/qgroups.pdf\|format = PDF\|title = Btrfs Subvolume Quota Groups\|first = Arne\|last = Jansen\|year = 2011\|publisher = Strato AG\|accessdate = 2012-11-14}} 76. ^¹{{cite web \| first = Jonathan \|last=Corbet \| date = 2 November 2011 \| accessdate = 12 February 2012 \| title = A btrfs update at LinuxCon Europe \| url = https://lwn.net/Articles/465160/ }} 77. ^¹²{{cite web\|date=21 February 2013\|accessdate=21 February 2013\|title=Btrfs Project ideas\|url=https://btrfs.wiki.kernel.org/index.php/Project_ideas }} 78. ^¹²³⁴{{cite web \| url = https://lwn.net/Articles/342892/ \| title = A short history of btrfs \| publisher = LWN.net \| first= Valerie \|last=Aurora \| date = 22 July 2009 \| accessdate = 5 November 2011 }} 79. ^¹²{{cite web \| url = https://btrfs.wiki.kernel.org/index.php/UseCases \| title = UseCases – btrfs documentation \| accessdate = 2013-11-04 \| website = kernel.org}} 80. ^¹²{{cite web \| url = https://blogs.oracle.com/OTNGarage/entry/save_disk_space_on_linux \| title = Save disk space on Linux by cloning files on Btrfs and OCFS2 \| date = 2011-08-31 \| accessdate = 2013-10-17 \| author = Lenz Grimmer \| website = oracle.com}} 81. ^¹²³{{cite web \| url = http://docs.oracle.com/cd/E37670_01/E37355/html/ol_use_case3_btrfs.html \| title = 5.6 Creating Subvolumes and Snapshots [needs update] \| year = 2013 \| accessdate = 2013-10-31 \| website = oracle.com}} 82. ^¹²³⁴{{cite web \| url = https://btrfs.wiki.kernel.org/index.php/SysadminGuide \| title = SysadminGuide – Btrfs documentation \| accessdate = 2013-10-31 \| website = kernel.org}} 83. ^¹²{{cite web \| url = http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html \| title = 5.7 Using the Send/Receive Feature \| year = 2013 \| accessdate = 2013-10-31 \| website = oracle.com}} 84. ^¹²³⁴{{cite web \| url = https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3 \| title = Conversion from Ext3 (Btrfs documentation) \| first = Chris \| last = Mason \| date = 2015-06-25 \| accessdate = 2016-04-22 \| website = kernel.org}} 85. ^¹{{citation\|url = http://linuxfoundation.ubicast.tv/videos/permalink/123/\|title = Btrfs Filesystem: Status and New Features\|publisher = Linux Foundation\|date = 2012-04-05\|accessdate = 2012-11-16\|first = Chris\|last = Mason}}{{Dead link\|date=November 2018 \|bot=InternetArchiveBot \|fix-attempted=yes }} 86. ^¹{{cite web\|title=btrfsck \|url=https://btrfs.wiki.kernel.org/index.php/Btrfsck}} 87. ^¹{{Cite conference \|last=Rodeh \|first=Ohad \|title=B-trees, shadowing, and clones \|conference=USENIX Linux Storage & Filesystem Workshop \|year=2007 \|url=https://www.usenix.org/legacy/events/lsf07/tech/rodeh.pdf}} Also {{Cite journal \|last=Rodeh \|first=Ohad \|year=2008 \|title=B-trees, shadowing, and clones \|journal=ACM Transactions on Storage}} 88. ^¹²³⁴⁵{{cite web \| url = http://btrfs.wiki.kernel.org/articles/b/t/r/Btrfs_design.html \| first = Chris \|last=Mason \| work = Btrfs wiki \| accessdate = 8 November 2011 \| title = Btrfs design }} 89. ^¹{{cite web \| title = Hard Link Limitation \| date = 8 August 2010 \| accessdate = 2011-11-14 \| work = kerneltrap.org \| url = http://kerneltrap.org/mailarchive/linux-btrfs/2010/8/2/6885208/thread }} 90. ^¹²{{cite web \| url = http://www.oracle.com/technetwork/articles/servers-storage-admin/advanced-btrfs-1734952.html \| title = How I Use the Advanced Capabilities of Btrfs \| date = August 2012 \| accessdate = 2013-09-20 \| first1 = Margaret \| last1 = Bierman \| first2 = Lenz \| last2 = Grimmer}} ^[70]^[71]^[72]^[73]^[74]^[75]^[76]^[77]^[78]^[79]^[80]^[81]^[82]^[83]^[84]^[85]^[86]^[87]^[88]^[89]^[90] }} External links {{Official website\|https://btrfs.wiki.kernel.org/}} {{YouTube\|id=hxWuaozpe2I\|title=I Can't Believe This is Butter! A tour of btrfs}}{{snd}} a conference presentation by Avi Miller, an Oracle engineer [https://lwn.net/Articles/577961/ Btrfs: Working with multiple devices]{{snd}} LWN.net, December 2013, by Jonathan Corbet Marc's Linux Btrfs posts{{snd}} detailed insights into various Btrfs features Btrfs overview, LinuxCon 2014, by Marc Merlin File System Evangelist and Thought Leader: An Interview with Valerie Aurora, Linux Magazine, 14 July 2009, by Jeffrey B. Layton {{Filesystem}}{{Linux kernel}}{{Linux}} 3 : Compression file systems\|File systems supported by the Linux kernel\|Linux file system-related software
随便看	Ševkija Resić Ševčíková Šećerović ŠEŠ (brother Sumerogram) Šeḫa Šiauliai Air Base Šiauliai (airport) Šiauliai Cathedral Šiauliai Gymnasium Šiauliai International Šiauliai (international airport) Šiaulių Juliaus Janonio gimnazija Šibovi Šibovi, Kotor Varoš Šibovi (Kotor Varoš) Šics Šid railway station Šijan Šilalė District Šiljakovina Šilovo Šilovo (disambiguation) Šilperk Šilutė airfield Šilutė Airport