Jump to content

Btrfs

From Wikipedia, the free encyclopedia

Btrfs
Developer(s)SUSE,Meta,Western Digital,Oracle Corporation,Fujitsu,Fusion-io,Intel,The Linux Foundation,Red Hat,andStrato AG[1]
Full nameB-tree file system
IntroducedMarch 23, 2009;15 years ago(2009-03-23)with Linux kernel 2.6.29
Partition IDs
  • MBR:0x83: Linux native filesystem
  • GPT:0FC63DAF-8483-4772-8E79-3D69D8477DE4: Linux native filesystem[2]
Structures
Directory contentsB-tree
File allocationExtents
Bad blocksNone recorded
Limits
Max volume size16EiB[3][a]
Max file size16 EiB[3][a]
Maxno.of files264[b][4]
Max filename length255ASCIIcharacters (fewer for multibytecharacter encodingssuch asUnicode)
Allowed filename
characters		All except'/'andNUL('\0')
Features
Dates recordedCreation (otime),[5]modification (mtime), attribute modification (ctime), and access (atime)
Date range64-bit signed int offset from 1970-01-01T00:00:00Z[6]
Date resolutionNanosecond
AttributesPOSIXandextended attributes
File system
permissions		Unix permissions,POSIX ACLs
Transparent
compression		Yes (zlib,LZO[7]and (since 4.14)ZSTD[8])
Transparent
encryption		Planned[9]
Data deduplicationYes[10]
Copy-on-writeYes
Other
Supported
operating systems		Linux,Windows,[11]ReactOS[12]
Websitedocs.kernel.org/filesystems/btrfs.htmlEdit this at Wikidata

Btrfs(pronounced as "better F S",[9]"butter F S",[13][14]"b-tree F S",[14]or B.T.R.F.S.) is a computer storage format that combines afile systembased on thecopy-on-write(COW) principle with alogical volume manager(not to be confused with Linux'sLVM), developed together. It was created by Chris Mason in 2007[15]for use inLinux,and since November 2013, the file system's on-disk format has been declared stable in the Linuxkernel.[16]

Btrfs is intended to address the lack ofpooling,snapshots,checksums,and integral multi-device spanning inLinux file systems.[9]Mason, the principal Btrfs author, 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".[17]

History

[edit]
Screenshot of usage information of a Btrfs filesystem

The core data structure of Btrfs‍—the copy-on-writeB-tree‍—was originally proposed byIBMresearcher Ohad Rodeh at aUSENIXconference in 2007.[18]Mason, an engineer working onReiserFSforSUSEat the time, joined Oracle later that year and began work on a new file system based on these B-trees.[19]

In 2008, the principal developer of theext3andext4file 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".[20]Btrfs also has "a number of the same design ideas thatreiser3/4had ".[21]

Btrfs 1.0, with finalized on-disk format, was originally slated for a late-2008 release,[22]and was finally accepted into theLinux kernel mainlinein 2009.[23]SeveralLinux distributionsbegan offering Btrfs as an experimental choice ofroot file systemduring installation.[24][25][26]

In July 2011, Btrfs automaticdefragmentationandscrubbingfeatures were merged into version 3.0 of theLinux kernel mainline.[27]Besides Mason at Oracle, Miao Xie at Fujitsu contributed performance improvements.[28]In June 2012, Mason left Oracle forFusion-io,which he left a year later with Josef Bacik to joinFacebook.While at both companies, Mason continued his work on Btrfs.[29][19]

In 2012, two Linux distributions moved Btrfs from experimental to production or supported status:Oracle Linuxin March,[30]followed bySUSE Linux Enterprisein August.[31]

In 2015, Btrfs was adopted as the default filesystem forSUSE Linux Enterprise Server(SLE) 12.[32]

In August 2017, Red Hat announced in the release notes forRed Hat Enterprise Linux(RHEL) 7.4 that it no longer planned to move Btrfs to a fully supported feature (it's been included as a "technology preview" since RHEL 6 beta) noting that it would remain available in the RHEL 7 release series.[33]Btrfs was removed from RHEL 8 in May 2019.[34]RHEL moved from ext4 in RHEL 6 toXFSin RHEL 7.[35]

In 2020, Btrfs was selected as the default file system forFedora33 for desktop variants.[36]

Features

[edit]

List of features

[edit]

Implemented

[edit]

As of version 5.0 of the Linux kernel, Btrfs implements the following features:[37][38]

[edit]

Cloning

[edit]

Btrfs provides acloneoperation thatatomicallycreates a copy-on-write snapshot of afile.Such cloned files are sometimes referred to asreflinks,in light of the proposed associated Linux kernelsystem call.[55]

By cloning, the file system does not create a new link pointing to an existinginode;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.[56][57]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.[58]

Cloning should not be confused withhard links,which are directory entries that associate multiple file names with a single file. While hard links can be taken as different names for the same file, cloning in Btrfs provides independent files that initially share all their disk blocks.[58][59]

Support for this Btrfs feature was added in version 7.5 of theGNU coreutils,via the--reflinkoption to thecpcommand.[60][61]

In addition to data cloning (FICLONE), Btrfs also supports out-of-band deduplication viaFIDEDUPERANGE.This functionality allows two files with (even partially) identical data to share storage.[62][10]

Subvolumes and snapshots

[edit]
Example of snapshots of a Btrfs filesystem, managed with snapper

A Btrfs subvolume can be thought of as a separate POSIX filenamespace,mountableseparately by passingsubvolorsubvolidoptions to themount(8)utility. It can also be accessed by mounting the top-level subvolume, in which case subvolumes are visible and accessible as its subdirectories.[63]

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.[64]

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 tomount.The default subvolume can be changed as required.[64]

A Btrfssnapshotis 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.[63]

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.[63][64]

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.[56]

A subvolume in Btrfs is quite different from a traditionalLogical Volume Manager(LVM) logical volume. With LVM, a logical volume is a separateblock device,while a Btrfs subvolume is not and it cannot be treated or used that way.[63]Making dd or LVM snapshots of btrfs leads to data loss if either the original or the copy is mounted while both are on the same computer.[65]

Send–receive

[edit]

Given any pair of subvolumes (or snapshots), Btrfs can generate a binarydiffbetween them (by using thebtrfs sendcommand) that can be replayed later (by usingbtrfs 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][66]

The send/receive feature can be used with regularly scheduled snapshots for implementing a simple form of file systemreplication,or for the purpose of performingincremental backups.[49][66]

Quota groups

[edit]
Example of Btrfs quota groups

Aquota group(orqgroup) 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 thebtrfs qgroupcommand) into hierarchies to implement quota pools.[51]

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

[edit]

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. Thebtrfs-converttool exploits this ability to do an in-place conversion of an ext2/3/4 orReiserFSfile system, by nesting the equivalent Btrfs metadata in its unallocated space—while preserving an unmodified copy of the original file system.[67]

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).[67]

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.[67]

In 4.x versions of the mainline Linux kernel, the in-place ext3/4 conversion was considered untested and rarely used.[67]However, the feature was rewritten from scratch in 2016 forbtrfs-progs4.6.[47]and has been considered stable since then.

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

Union mounting / seed devices

[edit]

When creating a new Btrfs, an existing Btrfs can be used as a read-only "seed" file system.[69]The new file system will then act as a copy-on-write overlay on the seed, as a form ofunion 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 aLive CDinstaller, 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.[70]

Encryption

[edit]

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

As of 2020,the developers were working to add keyed hash likeHMAC(SHA256).[72]

Checking and recovery

[edit]

Unix systems traditionally rely on "fsck"programs to check and repair filesystems. This functionality is implemented via thebtrfs checkprogram. Since version 4.0 this functionality is deemed relatively stable. However, as of December 2022, the btrfs documentation suggests that its--repairoption be used only if you have been advised by "a developer or an experienced user".[73]As of August 2022, the SLE documentation recommends using a Live CD, performing a backup and only using the repair option as a last resort.[74]

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

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.[77]This period can be changed by specifying a desired value (in seconds) with thecommitmount option.[78][79]

Design

[edit]

Ohad Rodeh's original proposal at USENIX 2007 noted thatB+ 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 copied on write, its siblings and parents would have to be as well, as wouldtheirsiblings and parents and so on until the entire tree was copied. He suggested instead a modifiedB-tree(which has no leaf linkage), with arefcountassociated 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 goodconcurrency.[18]

At Oracle later that year, 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.[80]

Btrfs is structured as several layers of such trees, all using the same B-tree implementation. The trees store genericitemssorted by a 136-bit key. The most significant 64 bits of the key are a uniqueobject id.The middle eight bits are an item type field: its use is hardwired into code as an item filter in tree lookups.Objectscan have multiple items of multiple types. The remaining (least significant) 64 bits are used in type-specific ways. Therefore, items for the same object end up adjacent to each other in the tree, grouped by type. By choosing certain key values, objects can further put items of the same type in a particular order.[80][4]

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.[80]

File system tree

[edit]

Within each directory, directory entries appear asdirectory items,whose least significant bits of key values are aCRC32Chash of their filename. Their data is alocation key,or the key of theinodeitem 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, effectivelyrandomly permutingthem. 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 asReiserFS,[81]ext3 (with Htree-indexes enabled[82]) and ext4, all of which haveTEA-hashed filenames. To avoid this, each directory entry has adirectory index item,whose 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 stored on disk.

Files with hard links in multiple directories have multiple reference items, one for each parent directory. Files with multiple hard links in thesamedirectory 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 asgit,GNUS,GMameandBackupPCwere observed to fail at this limit.[83]The limit was eventually removed[84](and as of October 2012 has been merged[85]pending release in Linux 3.7) by introducing spilloverextended reference itemsto hold hard link filenames which do not otherwise fit.

Extents

[edit]

File data is kept outside the tree inextents,which are contiguous runs of disk data blocks. Extent blocks default to 4 KiB 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 haveextent data itemsto track the extents which hold their contents. The item's 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 createbookend 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.[4]

Extent allocation tree

[edit]

Theextent allocation treeacts as an allocation map for the file system. Unlike other trees, items in this tree do not have object ids. They represent regions of space: their key values hold the starting offsets and lengths of the regions they represent.

The file system divides its allocated space intoblock groupswhich are variable-sized allocation regions that alternate 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 use concepts of theOrlov block allocatorto allocate related files together and resist fragmentation by leaving free space between groups. (Ext3 block groups, however, have fixed locations computed from the size of the file system, whereas those in Btrfs are dynamic and created as needed.) Each block group is associated with ablock group item.Inode items in the file system tree include a reference to their current block group.[4]

Extent itemscontain 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 individualextent 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 scan 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 itself to change. To avoid creating afeedback loop,extent tree nodes which are still in memory but not yet committed to disk may be updated in place to reflect new copied-on-write extents.

In theory, the extent allocation tree makes a conventionalfree-space bitmapunnecessary because the extent allocation tree acts as a B-tree version of aBSP tree.In practice, however, an in-memoryred–black treeofpage-sized bitmaps is used to speed up allocations. These bitmaps are persisted to disk (starting in Linux 2.6.37, via thespace_cachemount option[86]) as special extents that are exempt from checksumming and copy-on-write.

Checksum tree and scrubbing

[edit]
See also:Silent data corruption

CRC-32Cchecksums are computed for both data and metadata and stored aschecksum itemsin achecksum tree.There is room for 256 bits of metadata checksums and up to a full node (roughly 4 KB or more) for data checksums. Btrfs has provisions for additional checksum algorithms to be added in future versions of the file system.[37][87]

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 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 – if internal mirroring or RAID techniques are in use.[88][89]

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.[88][90]

Log tree

[edit]

Anfsyncrequest commits modified data immediately to stable storage. fsync-heavy workloads (like adatabaseor avirtual machinewhose running OSfsyncsfrequently) 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-subvolumelog treeis created tojournalfsync-triggered copies on write. 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

[edit]

Block devicesare divided intophysical chunksof 1 GiB for data and 256 MiB for metadata.[91]Physical chunks across multiple devices can be mirrored or striped together into a singlelogical chunk.These logical chunks are combined into a single logical address space that the rest of the filesystem uses.

Thechunk treetracks this by storing each device therein as adevice itemand logical chunks aschunk map items,which provide a forward mapping from logical to physical addresses by storing their offsets in the least significant 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 2 physical chunks across 2 out of N≥2 block devices,[92]in contrast to conventionalRAID 1which has N physical chunks
raid1c3
1 logical chunk to 3 physical chunks out of N≥3 block devices
raid1c4
1 logical chunk to 4 physical chunks out of N≥4 block devices
raid5
N (for N≥2) logical chunks to N+1 physical chunks across N+1 block devices, with 1 physical chunk used as parity
raid6
N (for N≥2) logical chunks to N+2 physical chunks across N+2 block devices, with 2 physical chunks used as parity

Nis the number of block devices still having 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.

Relocation trees

[edit]

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 specialrelocation treeserving 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.[93]

Superblock

[edit]

All the file system's trees—including the chunk tree itself—are stored in chunks, creating a potentialbootstrappingproblem whenmountingthe file system. Tobootstrapinto a mount, a list of physical addresses of chunks belonging to the chunk and root trees are stored in thesuperblock.[94]

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

Commercial support

[edit]

Supported

[edit]
See also:List of default file systems

No longer supported

[edit]

See also

[edit]

Notes

[edit]
  1. ^abThis is the Btrfs' own on-disk size limit. The limit is reduced down to 8EiBon 64-bit systems and 2 EiB on 32-bit systems due to Linux kernel's internal limits, unless kernel'sCONFIG_LBDconfiguration option (available since the2.6.x kernel series) is enabled to remove these kernel limits.[103][104]
  2. ^Every item in Btrfs has a 64-bit identifier, which means the most files one can have on a Btrfs filesystem is 264.

References

[edit]
  1. ^"Contributors at BTRFS documentation".kernel.org. 15 June 2022.Retrieved5 December2022.
  2. ^"GPT fdisk - ArchWiki".
  3. ^ab"Suse Documentation: Storage Administration Guide – Large File Support in Linux".SUSE.Retrieved12 August2015.
  4. ^abcdMason, Chris."Btrfs design".Btrfs wiki.Retrieved8 November2011.
  5. ^Corbet, Jonathan (26 July 2010)."File creation times".LWN.net.Retrieved15 August2015.
  6. ^"On-disk Format - btrfs Wiki".btrfs.wiki.kernel.org.
  7. ^ab"btrfs Wiki".kernel.org.Retrieved19 April2015.
  8. ^ab"Linux_4.14 - Linux Kernel Newbies".kernelnewbies.org.
  9. ^abcMcPherson, Amanda (22 June 2009)."A Conversation with Chris Mason on BTRfs: the next generation file system for Linux".Linux Foundation.Archived fromthe originalon 27 June 2012.Retrieved1 September2009.
  10. ^abc"Deduplication".kernel.org.Retrieved19 April2015.
  11. ^"Windows Driver on GitHub.com".GitHub.Retrieved10 January2023.
  12. ^"ReactOS 0.4.1 Released".reactos.org.Retrieved11 August2016.
  13. ^"Oracle Linux 7 Q&A with Wim Coekaerts".Oracle.Event occurs at 1m 15s. Archived fromthe originalon 18 August 2016.Retrieved6 February2016.
  14. ^abHenson, Valerie (31 January 2008).Chunkfs: Fast file system check and repair.Melbourne,Australia. Event occurs at 18m 49s.Retrieved5 February2008.It's called Butter FS or B-tree FS, but all the cool kids say Butter FS
  15. ^Salter, Jim (24 September 2021)."Examining btrfs, Linux's perpetually half-finished filesystem".Ars Technica.Retrieved11 June2023.Chris Mason is the founding developer of btrfs, which he began working on in 2007 while working at Oracle. This leads many people to believe that btrfs is an Oracle project—it is not. The project belonged to Mason, not to his employer, and it remains a community project unencumbered by corporate ownership to this day.
  16. ^"Linux kernel commit changing stability status in fs/btrfs/Kconfig".Retrieved8 February2019.
  17. ^Kerner, Sean Michael (30 October 2008)."A Better File System for Linux?".InternetNews.com.Archivedfrom the original on 8 April 2011.Retrieved27 August2020.
  18. ^abRodeh, Ohad (2007).B-trees, shadowing, and clones(PDF).USENIXLinux Storage & Filesystem Workshop.AlsoRodeh, Ohad (2008). "B-trees, shadowing, and clones".ACM Transactions on Storage.3(4): 1–27.doi:10.1145/1326542.1326544.S2CID207166167.
  19. ^ab"Lead Btrfs File-System Developers Join Facebook".phoronix.com.Retrieved19 April2015.
  20. ^Paul, Ryan (13 April 2009)."Panelists Ponder the Kernel at Linux Collaboration Summit".Ars Technica.Archived fromthe originalon 17 June 2012.Retrieved22 August2009.
  21. ^Ts'o, Theodore (1 August 2008)."Re: reiser4 for 2.6.27-rc1".linux-kernel(Mailing list).Retrieved31 December2010.
  22. ^"Development timeline".Btrfs wiki.11 December 2008. Archived fromthe originalon 20 December 2008.Retrieved5 November2011.
  23. ^Wuelfing, Britta (12 January 2009)."Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem".Linux Magazine.Retrieved5 November2011.
  24. ^ab"Red Hat Enterprise Linux 6 documentation: Technology Previews".Archived fromthe originalon 28 May 2011.Retrieved21 January2011.
  25. ^"Fedora Weekly News Issue 276".25 May 2011.
  26. ^"Debian 6.0" Squeeze "released"(Press release).Debian.6 February 2011.Retrieved8 February2011.Support has also been added for the ext4 and Btrfs filesystems...
  27. ^ab"Linux kernel 3.0, Section 1.1. Btrfs: Automatic defragmentation, scrubbing, performance improvements".kernelnewbies.org.21 July 2011.Retrieved5 April2016.
  28. ^Leemhuis, Thorsten (21 June 2011)."Kernel Log: Coming in 3.0 (Part 2) - Filesystems".The H Open.Retrieved8 November2011.
  29. ^Varghese, Sam."iTWire".ITWire.com.Retrieved19 April2015.
  30. ^"Unbreakable Enterprise Kernel Release 2 has been released".Retrieved8 May2019.
  31. ^"SLES 11 SP2 Release Notes".21 August 2012.Retrieved29 August2012.
  32. ^"SUSE Linux Enterprise Server 12 Release Notes".5 November 2015.Retrieved20 January2016.
  33. ^ab"Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality".1 August 2017. Archived fromthe originalon 8 August 2017.Retrieved15 August2017.
  34. ^ab"Considerations in adopting RHEL 8".Product Documentation for Red Hat Enterprise Linux 8.Red Hat.Retrieved9 May2019.
  35. ^"How to Choose Your Red Hat Enterprise Linux File System".4 September 2020.Retrieved3 January2022.
  36. ^"Btrfs Coming to Fedora 33".Fedora Magazine.24 August 2020.Retrieved25 August2020.
  37. ^ab"Btrfs Wiki: Features".btrfs.wiki.kernel.org.27 November 2013.Retrieved27 November2013.
  38. ^"Btrfs Wiki: Changelog".btrfs.wiki.kernel.org.29 May 2019.Retrieved27 November2013.
  39. ^"Manpage btrfs-check".
  40. ^"Using Btrfs with Multiple Devices".kernel.org.7 November 2013.Retrieved20 November2013.
  41. ^"Compression".kernel.org.25 June 2013.Retrieved1 April2014.
  42. ^"Btrfs: add support for inode properties".kernel.org.28 January 2014.Retrieved1 April2014.
  43. ^"btrfs: Readonly snapshots".Retrieved12 December2011.
  44. ^"Save disk space on Linux by cloning files on Btrfs and OCFS2".Retrieved1 August2017.
  45. ^"Wiki FAQ: What checksum function does Btrfs use?".Btrfs wiki.Retrieved15 June2009.
  46. ^"Btrfs hilights in 5.5: new hashes".Retrieved29 August2020.
  47. ^ab"Btrfs progs release 4.6".Retrieved1 August2017.
  48. ^Mason, Chris (12 January 2009)."Btrfs changelog".Archived fromthe originalon 29 February 2012.Retrieved12 February2012.
  49. ^abcCorbet, Jonathan (11 July 2012),Btrfs send/receive,LWN.net,retrieved14 November2012
  50. ^"Btrfs Wiki: Incremental Backup".27 May 2013.Retrieved27 November2013.
  51. ^abJansen, Arne (2011),Btrfs Subvolume Quota Groups(PDF),Strato AG,retrieved14 November2012
  52. ^"RAID 5/6".kernel.org. 16 July 2016.Retrieved1 October2016.
  53. ^Blaxell, Zygo."How to use btrfs raid5 successfully(ish)".lore.kernel.org.Retrieved26 June2022.
  54. ^Blaxell, Zygo."Current bugs with operational impact on btrfs raid5".lore.kernel.org.Retrieved26 June2022.
  55. ^Corbet, Jonathan (5 May 2009)."The two sides of reflink()".LWN.net.Retrieved17 October2013.
  56. ^ab"UseCases – btrfs documentation".kernel.org.Retrieved4 November2013.
  57. ^"btrfs: allow cross-subvolume file clone".github.com.Retrieved4 November2013.
  58. ^"Symlinks reference names, hardlinks reference meta-data and reflinks reference data".pixelbeat.org.27 October 2010.Retrieved17 October2013.
  59. ^Meyering, Jim (20 August 2009)."GNU coreutils NEWS: Noteworthy changes in release 7.5".savannah.gnu.org.Retrieved30 August2009.
  60. ^Scrivano, Giuseppe (1 August 2009)."cp: accept the --reflink option".savannah.gnu.org.Retrieved2 November2009.
  61. ^ioctl_fideduperange(2)–LinuxProgrammer'sManual– System Calls
  62. ^abcd"SysadminGuide – Btrfs documentation".kernel.org.Retrieved31 October2013.
  63. ^abc"5.6 Creating Subvolumes and Snapshots [needs update]".oracle.com.2013.Retrieved31 October2013.
  64. ^"Gotchas - btrfs Wiki".btrfs.wiki.kernel.org.
  65. ^ab"5.7 Using the Send/Receive Feature".oracle.com.2013.Retrieved31 October2013.
  66. ^abcdMason, Chris (25 June 2015)."Conversion from Ext3 (Btrfs documentation)".kernel.org.Retrieved22 April2016.
  67. ^"btrfs-convert(8) — BTRFS Documentation".Retrieved16 October2022.
  68. ^"Seed device".Archived fromthe originalon 12 June 2017.Retrieved1 August2017.
  69. ^Mason, Chris (5 April 2012),Btrfs Filesystem: Status and New Features,Linux Foundation,retrieved16 November2012[permanent dead link]
  70. ^McPherson, Amanda (22 June 2009)."A Conversation with Chris Mason on BTRfs: the next generation file system for Linux".Linux Foundation.Archived fromthe originalon 27 June 2012.Retrieved9 October2014.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.
  71. ^Sterba, David."authenticated file systems using HMAC(SHA256)".Lore.Kernel.org.Retrieved25 April2020.
  72. ^"btrfs-check(8)".btrfs.readthedocs.io.
  73. ^"How to recover from BTRFS errors | Support | SUSE".www.suse.com.Retrieved28 January2023.
  74. ^"Restore - btrfs Wiki".btrfs.wiki.kernel.org.
  75. ^"btrfs-restore(8) - Linux manual page".man7.org.Retrieved28 January2023.
  76. ^"Problem FAQ - btrfs Wiki".kernel.org.31 July 2013.Retrieved16 January2014.
  77. ^"kernel/git/torvalds/linux.git: Documentation: filesystems: add new btrfs mount options (Linux kernel source tree)".kernel.org.21 November 2013.Retrieved6 February2014.
  78. ^"Mount options - btrfs Wiki".kernel.org.12 November 2013.Retrieved16 January2014.
  79. ^abcAurora, Valerie (22 July 2009)."A short history of btrfs".LWN.net.Retrieved5 November2011.
  80. ^Reiser, Hans (7 December 2001)."Re: Ext2 directory index: ALS paper and benchmarks".ReiserFS developers mailing list.Retrieved28 August2009.
  81. ^Mason, Chris."Acp".Oracle personal web page.Archived fromthe originalon 16 May 2021.Retrieved5 November2011.
  82. ^Fasheh, Mark (9 October 2012)."btrfs: extended inode refs".Archived fromthe originalon 15 April 2013.Retrieved7 November2012.
  83. ^Torvalds, Linus (10 October 2012)."Pull btrfs update from Chris Mason".git.kernel.org.Archived fromthe originalon 15 April 2013.Retrieved7 November2012.
  84. ^Larabel, Michael (24 December 2010)."Benchmarks of the Btrfs Space Cache Option".Phoronix.Retrieved16 November2012.
  85. ^"FAQ - btrfs Wiki: What checksum function does Btrfs use?".The btrfs Project.Retrieved22 November2020.
  86. ^abBierman, Margaret; Grimmer, Lenz (August 2012)."How I Use the Advanced Capabilities of Btrfs".Retrieved20 September2013.
  87. ^Salter, Jim (15 January 2014)."Bitrot and Atomic COWs: Inside" Next-Gen "Filesystems".Ars Technica.Retrieved15 January2014.
  88. ^Coekaerts, Wim (28 September 2011)."Btrfs Scrub – Go Fix Corruptions with Mirror Copies Please!".Oracle.Retrieved20 September2013.
  89. ^"Glossary".Btrfs Wiki.Archived fromthe originalon 31 July 2021.Retrieved31 July2021.
  90. ^"Manpage/mkfs.btrfs".Btrfs Wiki.Profiles.Retrieved31 July2021.
  91. ^Mason, Chris; Rodeh, Ohad; Bacik, Josef (9 July 2012)."BTRFS: The Linux B-tree Filesystem"(PDF).IBM Research.Archived fromthe original(PDF)on 23 April 2014.
  92. ^Mason, Chris (30 April 2008)."Multiple device support".Btrfs wiki.Archived fromthe originalon 20 July 2011.Retrieved5 November2011.
  93. ^Bartell, Sean (20 April 2010)."Re: Restoring BTRFS partition".linux-btrfs(Mailing list).
  94. ^"Oracle Now Supports Btrfs RAID5/6 on Their Unbreakable Enterprise Kernel - Phoronix".Phoronix.com.
  95. ^"Managing Btrfs in Oracle Linux 8".docs.oracle.com.Retrieved6 June2020.[dead link]
  96. ^"SUSE Reaffirms Support for Btrfs".LWN.net.
  97. ^"SUSE Linux Enterprise Server 12 Release Notes".SUSE.com.Retrieved28 February2021.
  98. ^"Cloud Station White Paper"(PDF).Synology.com.Synology.p. 11. Archived fromthe original(PDF)on 11 November 2020.Retrieved2 April2021.Starting from DSM 6.0, data volumes can be formatted as Btrfs
  99. ^"Btrfs has been deprecated in RHEL".News.YCombinator.com.
  100. ^"Red Hat Appears to Be Abandoning Their Btrfs Hopes - Phoronix".Phoronix.com.
  101. ^Jaeger, Andreas (15 February 2005)."Large File Support in Linux".users.suse.com.Archived fromthe originalon 23 July 2015.Retrieved12 August2015.
  102. ^"Linux kernel configuration help for CONFIG_LBD in 2.6.29 on x86".kernel.xc.net.Archived fromthe originalon 6 September 2015.Retrieved12 August2015.
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Btrfs&oldid=1249451958"