Case Study On BTRFS: A Fault Tolerant File System

 

BtrFS: A fault tolerant file system Case Study

 Kumar Amit Amit Mehta Department of Computer Engineering Ta Tallinn llinn University of Technology Tallinn, Estonia [email protected]

 Abstract 

File system plays a crucial rule in storage fault tolerance, data recovery, scalability and performance of the system. Over the years several File system implementation, such as ext3, ext4, JFS, ZFS, XFS etc. have been deployed on servers running on Linux. Different file system offer different features and have different design goals. The design goal of BtrFS is scalability and storage fault tolerance. This paper describes challenges associated with a file system de desi sign gn,, di disc scus ussi sion on on Bt BtrF rFS S fa faul ultt tole tolera rant nt fe feat atur ures es,, performance perfor mance comparison comparison with existing solutions solutions followed by conclusion.  Keywords: Filesystems, Storage, BtrFS, BtrFS, Fault tolerance

I.

INTRODUCTION  

A file system is a storage abstraction that control how data is stored and retrieved from the storage device. Wi Without thout the file system, data is just a bunch of bits without any information about the data itself. Essentially, a file system is the methods and data structures that an operating system uses to keep track of files on a disk or partition. Due to numerous advantages, advantages, file sy syste stems ms are ba bare re min minimu imum m re requi quire remen ment, t, how howeve everr due to varying workloads, heterogeneous nature of storage hardware (S (SSD SD,, HDD DD,, JBOD, SATA, SA SAN N, NAS etc), tc), stri trict requir req uireme ements nts on da data ta consi consiste stency ncy and and da data ta rec recove overy ry on massively parallel systems with very high uptime requirement, it typically takes about 7 to 8 years of development and test cycles, before a new file system gains the the trust and is put into into pr prod oduc ucti tion on in en ente terp rpri rise se clas classs data data ce cent nter ers. s. Data Data unavailability, data loss or even worse, data corruption can have catastrophic effects   and unfortunately, faults, errors and failures (both hardware and software) are inevitable. There has been studies [2, 3] on data unavailability and it was found that data data unav unavai aila labi bili lity ty due due to st stor orag agee fa fail ilur ures es occu occurr quit quitee frequently,. frequently ,. Hence fault tolerance aspect of file systems design is given given a lot of consid considera eratio tion n and is perhaps perhaps the most most important feature of a file system. Currently there are more than 70 file system supported by Linux and each of these file system have different design goals. BtrFS, whose development work started in 2007 for Linux based hosts has Fault tolerance and scalability as the main design principle. Though still under heavy development, it is poised to become the next generation file system for ente enterpris rprisee class class infrastru infrastructure cture.. It has ideas borrowed from other commercial level file systems and have

integrated many more features, which its predecessors were lacking. A fault tolerant system can cause severe performance penalties, rendering it to be not scalable, but BtrFS overcomes those challenges very well [7, 8]. This paper is a case study on the short comings of current storage fault tolerance design, no nove vell idea ideass in Bt BtrF rFS, S, it' it's faul faultt tole tolera rant nt feat featur urees, an and d comparison with existing solutions.

II.

BACKGROUND

 A. Historical perspective BtrFS is an open source file system that has seen extensive development since its inception in 2007. It is jointly developed by Fujitsu , Fusion-IO , Intel ,Oracle , Red Hat , Strato , SUSE , and many others. It is slated to become the next major ™

™

™

™

™

™

™

Linux Lin ux file file syste system. m. It was was mer merge ged d into into the ma mainl inline ine Lin Linux ux kernel in the beginning of 2009 and debuted in the Linux 2.6.29 release. BtrFS is not a successor to the default Ext4 file system used in most Linux distributions, but it is expected to replace Ext4 in the future. BtrFS is expected to offer better scalabil sca lability ity and reliability reliability.. It is a copy-on-w copy-on-write rite file system intended to address various weaknesses in current Linux file systems. It is expected to work well on systems as small as a smartphone,, and as large as an enterprise production server. As smartphone such, it must work well on a wide range of hardware. It's main features are: 1. CRCs maintained for all metadata and data 2. Efficient writeable snapshots 3. Multi-device support 4. Online resize and defragmentation 5. Compression 6. Efficient storage for small files 7. SSD optimizations and TRIM support 8. In built RAID functionality  B. Challenges  B.1  Ubiquitous B-trees for organization and maintenance of large ordered indexes   The file system on disk layout is a forest of b-tree b-treess [1] with copy-on-write (COW) as update method. Copy-on-write is an optimization strategy used in computer programming. Copyon-write has an added advantage that a crash during the update

 

procedure does not impact the original data. Normally, Normally, the data is loaded from disk to memory, modified, and then written elsewhere. The idea is not to update the original location in place, risking a power failure and partial update. However, Btrees in their native form are very incompatible with COW technique that help achieve shadowing and cloning (writable snap snapsh shot ots) s) feat featur ures es of Bt BtrF rFS. S. Sh Shad adow owin ing g is a po powe werf rful ul mechanism that has been used to implement snapshot, crashrecovery, write-batching and RAID. The basic scheme is to look at the file system as a large tree made up of fixed-sized pages. When a page is shadowed, its location on disk changes, and this update shadow) the immediate an ance cest stor or creates of th theea need pa page ge towi with th th thee(and new new addr addres ess. s. Sh Shad adow owin ing g propagates up to the file system root.

 B.2 Varying workloads   Workloads affect the ability of file systems to provide high performance to users. Because of the increasing gap between processor speed and disk latency, file system performance is largely determined by its disk behavior. Storage workloads are changing; more file storage, less block storage; larger file size, Enterprise, Engineering, Email, Backup and many more different types of workload [4] add to the complexity and the performance of file system.  B.3   Heterogene  B.3  Heterogeneous ous storage   The heterogeneous heterogeneou s nature of storage devices bring more complexity. The read and write policies, latency, aging and reliability of various storage devices are substantially different. A rotating disk typically does not have write leveling issues, while a SSD does not have to deal with wear and tear of rotating platter. C. Sto Stora rage ge ffau ault ltss

C.1 Mean time to failure of disks

Fig. 1. Shadowing a leaf (Ohad)

Figure 1 shows an initial file system with root A that contains seven nodes. After leaf node C is modified, a complete path to the root is shadowed, creating a new tree rooted at A’. Nodes A, B, and C become unreachable and will later be deallocated. The b-tree variant typically used by file systems is b+-trees. In a b+-tree, leaf nodes contain data values and internal nodes contain only indexing keys. Files are typically represented by b-trees that hold disk extents in their leaves and leaves are chained together for rebalancing purposes. However such scheme becomes extremely inefficient for copy-on-write style file system.

  MTTF of disk C Component omponent failure in lar large-scale ge-scale IT installations is becoming an ever-larger problem as the number of components in a single cluster approaches a million. Study result [2, 3] have shown that the mean time-to-failure (MTTF) of storage drives such as SCSI and FC, as well as SATA interfaces, as specified in their datasheets are more than the ranges (1,000,000 to 1,500,000 hours) specified in their datasheets.. It was found that in the field, annual disk datasheets replacement rates typically exceed 1%, with 2–4% common and up to 13% observed on some systems. It is often assumed that the disk failures follow a simple fail-stop model, however, disk failures are much more complex in reality. For example, disk drives can experience latent sector faults or transient performance problems. Often it is hard to correctly attribute the root cause of a problem to a particular hardware component. component. Table I shows the relative frequency of Hardware Component Replacements for the ten most frequently replaced components in High performance Computing(HPC1) and cluster system (COM1, COM2) in a large internet service provider infrastructure. TABLE I.  I.

SCHROEDER AND GARTH

Fig. 2. A tree whose leaves are chained together (Ohad)

Figure 2 shows a tree whose rightmost leaf node is C and where the leaves are linked from left to right. If C is updated, the entire tree needs to be shadowed. Without leaf pointers, only C, B, and A require shadowing. In such B-trees, with shadowing each change has to be propagated up to the root. Hence the major challenge is to achieve benefits of shadowing mechanism, while retaining the ubiquitous B-trees for organization and maintenance of large ordered indexes.

C.2. Bitot    Bitrot [9] is the silent co corruption rruption of data on disk or tape. One One at a time, year by year, a random bit here or there gets flipped. The worst thing is that the backup won't save the user, since backups are completely oblivious to bitrot. Conventional RAID doesn't help either. Though RAID5 array can rebuild the data from the parity, but that only works if the drive fails completely

 

Fig. 3. Original image

Fig. 4. After flipping one bit

and cleanly. If the drive instead starts spewing corrupted data, the array may or may not notice the corruption. Even if it does notice, all the array knows is that something in the stripe is bad, it has no way of know knowing ing which which drive  drive returned bad data—and therefore which one to rebuild from parity (or whether the parity block itself was corrupt). Figure 3 and 4 shows an effect effect of bitrot on a jpg image. As can be seen here, even a small hardware error can corrupt the data significantly. C.3. Journaling is not enough   Most of the file system system today use a technique called called Journing. A journal journal is a special log file stored on a persistent storage media, in which file system writes all its actions before actually performing them. If the system crashes while the file system is performing an action, the file system can complete the pending action(s) upon the next system boot, by referring the journal and replaying the log. Journaling file system has a big problem; they can only provide metadata integrity and consistency.. Keeping both data and metadata changes inside consistency the journal introduces an unacceptable performance overhead, hence file system end up only keeping logs for the metadata update. A fault tolerant file system s ystem should provide both metadata and data integrity and consistency without much overhead.

III.

BTRFS DISCUSSION

Fig. 5. (a) A basic b-tree (b) Inserting key 19, and creating a path of modified pages. (Ohad) In order order to rem remove ove a key key,, copycopy-onon-wri write te is use used. d. Remov Removee operations do not modify pages in place. For example, Figure 6 shows how key 6 is removed from a tree. Modifications are written off to the side, creating a new version of the tree.

Fig. 6. (a) A basic tree (b) Deleting key 6.

In order to clone a tree, its root node is copied, and all the child pointers are duplicated. For example, Figure 7 shows a tree Tp, that is cloned to tree Tq . Tree nodes are denoted by symbols. As modifications will be applied to Tq, sharing will be lost between the trees, and each tree will have its own view of the data.

 A. COW friendly B-tree B-trees in their normal form was posing a big performance penalty for copy-on-write based update method. method. In 2007, Ohad Rodeh published a paper [5] on COW friendly B-trees, which introduced some novel idea on shadowing and clones. Those ideas were adopted in the design of BtrFS [6]. The main idea is to use standard b+-tree construction, but (1) employ a topdown update procedure, (2) remove leaf-chaining, (3) use lazy reference-counting reference-co unting for space management. Figure 5(a) shows an initial tree with two levels. Unmodified pages are colored yellow, and COWed pages are colored green. Figure 5(b) shows an insert of new key 19 into the right most leaf. A path is traversed down the tree, and all modified pages are written to new locations, without modifying the old pages.

Fig. 7. Cloning tree Tp. A n new ew root Q is created, initially pointing to the same blocks as the original root P. As modifications will be applied, the trees will diverge.(Ohad).

 

Since tree nodes can be reached from multiple roots, garbage collection is needed for space reclamation. As the trees are acyclic, reference counting is used to track pointers to treenodes. Once the counter reaches zero, a block can be reused. In order to keep track of ref-counts, the copy-on-write mechanism is modified. Whenever a node is COWed, the ref-count for the original is decremented, and the ref-counts for the children are incremen incr emented. ted. BtrFS uses this spac spacee recl reclamat amation ion process process in background.  B.  Data and metadata checksum checksum  metadata CRC32C are computed data andtree. andchecksums stored as checksum itemsfor inboth a checksum There is one checksum item per contiguous run of allocated blocks, with per-block checksums packed end-to-end into the item data. When 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. Even on a non RAID file system, btrfs usually has two copies of metadata which are both checksummed . Data blocks are not duplicated duplicated unless one has RAID1 or higher, but they are checksummed. Scrub [10] will therefore know if metadata is corrupted and typically correct it on its own It can also tell if, data blocks got corrupted, auto fix them if RAID allows, or report them in syslog otherwise. To tes testt this feature, feature, a virtual virtual machine, machine, was created. created. Latest Latest stable release of Linux (kernel version 3.17.4) was installed. Two virtual disks were added to the virtual machine and were formatted as BtrFS file system, with BtrFS built in software raid level 1 for both data and metadata. Data corruption was performed over the disk itself, underneath the file system so that file system has no idea. However, when an attempt was made to read the same data through the file system layer, BtrFS not on only ly detect detected ed the error error,, but also also corre correct cted ed the da data. ta. Following message were seen in the system logs.

file system still only sees a single copy of each block, it can only say that the checksum is broken but cannot recover. Therefore BtrFS does it own device management. It calculates checksums, stores them in a separate tree, and is then better position posi tioned ed to reco recover ver data when when media media erro errors rs occu occur. r. BtrFS splits each device into large chunks. A chunk tree maintains a mapping of logical to physical chunks. A device tree maintains revers rev ersee ma mappi pping. ng. The rest rest of the file file syste system m sees sees log logica icall chunks. Physical chunks are divided into groups according to the required RAID level of the logical chunk. For mirroring, chunks are divided into pairs. Table II presents an example with wit h three three disks, disks, and and groups groups of two two.. For examp example, le, logica logicall chunk L1 is made up of physical chunks C11 and C21 . TABLE II  II. TO SUPPORT RAID1 LOGICAL CHUNKS, PHYSICAL CHUNKS ARE DIVIDED INTO PARTS. HERE THERE ARE THREE DISKS, EACH WITH TWO PHYSICAL CHUNKS PROVIDING THREE LOGICAL CHUNKS. LOGICAL CHUNK L1 IS BUILT OUT OF PHYSICAL CHUNKS C11 AND C21

Logical chunks

Disk 1

L1

C11

Disk 2 C21

L2

C22

L3

Disk 3

C31

C12

For striping (RAID0), groups of n chunks are used, where each physical chunk is on a different disk. For example, Table 3 shows stripe width of four (n = 4), with four disks, and three logical chunks. TABLE II  III. STRIPING WITH FOUR DISKS, STRIPE WIDTH IS N= 4. 4 . THREE LOGICAL CHUNKS ARE EACH MADE UP OF FOUR PHYSICAL CHUNKS

Logical chunks

Disk 1

Disk 2

Disk 3

Disk 4

BTRFS info (de BTRFS (devic vicee sd sdb): b): csum faile failed d ino 257 off off 0 cs csum um 2566472073 expected csum 3681334314

L1

C11

C21

C31

C41

L2

C12

C22

C32

C42

BTRFS info (de BTRFS (devic vicee sd sdb): b): csum faile failed d ino 257 off off 0 cs csum um 2566472073 expected csum 3681334314

L3

C13

C23

C33

C43

BTRFS: BTRF S: read read error error corr correcte ected: d: ino 257 off 0 (dev /dev/s /dev/sdc dc sector 449512) C. Multi-de Multi-device vice support  support    The device mapper [11] subsystem in Linux manages storage devices. For example, LVM and mdadm. These are software modules whose primary function is to take raw disks, merge them into a virtually virtually contiguous contiguous block address address space, and export expo rt that abstra abstraction ction to higher higher level level kern kernel el layers. layers. They supp suppor ortt mi mirr rror orin ing, g, st stri ripi ping ng,, an and d RA RAID ID5/ 5/6. 6. Ho Howe weve verr, checksums are not supported. This causes problem for BtrFS, which maintains checksum for each block. Consider a case where data is stored in RAID-1 form on disk, and each 4KB block blo ck ha hass an additi additiona onall copy copy.. If the the file file sy syste stem m det detect ectss a checksum error on one copy, it needs to recover from the other copy. Device mapper hide that information behind the virtual address space abstraction, and return one of the copies. Since

 D. Subvolumes Subvolumes provide an alternative restricted view of the fi file le syst system em.. Each Each su subv bvol olum umee ca can n be trea treate ted d as its its own own filesyst file system em and mounted mounted sepa separate rately ly and exposed exposed as need needed. ed. Exposing only a part of a file system, restricts the damage to the entire entire file file syste system. m. A subvo subvolum lumee [12] [12] in btrfs btrfs has has its hi hier erar arch chy y an and d rela relati tion onss be betw twee een n ot othe herr subv subvol olum umes es.. A subvolume in btrfs can be accessed in two ways, (i)From the parent subvolume when accessing from the parent subvolume, the subvolume can be used just like a directory. It can have child chil d subv subvolum olumes es and its own files/dir files/directo ectories ries.. (ii) Separate Separate mounte mou nted d filesy filesyste stem. m. Fro From m outsid outside, e, subvol subvolume umess loo look k like like ordinary ordin ary directory structure; structure; one can copy thin things gs into that directory (which thus puts them into that subvolume), one can create other directories under that subvolume directory, and can even create other subvolumes under it, however in reality they are not. An attempt attempt to create create hard hardlinks links across subvolu subvolumes mes won't work. Subvolumes are extremely easy to manage when

 

taking a snapshot. These snapshot of subvolume can be readonly as well. Since Since BtrFS is copy-on-write copy-on-write based file file system, the snapshot initially consume no additional disk space and will only start to use space if its files are modified, or new files are created.  E. Snapshot    One of the requirement requirement for mission critical critical sy system stem is to be able to recover from failures. Snapshots are one such mechanism. Snapshot is a state of a system (In this case data) at a particular point in time. Using snapshot, one can go back to a particular time in history and recover data. Snapshots are built in BtrFS and cost little performance, especially compared to LVM (Logical Volume Volume Manager). In BtrFS, a snapshot is a cheap atomic copy of a subvolume, stored on the same file system as the original. Snapshot volume looks similar to a full backup taken at a particular point. For example, consider a file of size 10GB, it takes up 10GB of space. At this point (sa (say y at Time 't') snapshot is taken, the file and the snapshot between them take up 10GB of space. Later 1GB of the file is modified, and now the file and the snapshot take up 11GB of space; 9GB is unmodified and is still shared. Only the remaining 1GB has two different versions. This approach has tremendous space savings. These read-only snapshots can be sent to another file system or machine using send/receive to cancel out single point of failure. A snapshot snapshot in Btrfs is a special type of subvolume; one which contains a copy of the

seen in the field. At At the end of the day, day, what matters to a user is the robustnes robustnesss and performance for his particular application. 1000 surprising power failure test result [7] show that Ext4 metadata meta data was corrupte corrupted, d, while while BtrF BtrFS S work worked ed without without any problem. The power failure test was done on Freescale TWRVF65GS10 board, 1GB DDR3 memory and 16GB Micro SD Card. Linux kernel version used was 3.15-rc7. The board was periodically turned On and Off, while a file writing application was continuously creating 4KB files. TABLE IV.

Number of  Power Failure

POWER FAILURE TEST RESULTS

Results

BtrFS

1000+

No Abnormal situation occurred

Ext4

1000+

Corrupted inode had increased up to 32,000 and Finally Finally Fel Felll int into o Abnormal Abnormal Disk Full State

  Table IV shows the robustness test results. It is perhaps the copy-on-w copy -on-write rite feat feature ure of BtrF BtrFS S that sus sustain tained ed such abrupt power failures. Performance test results [6, 7] show that despite supporting new features such as Snapshot, data checksum and multiple device support, BtrFS provides reasonable performance under most workloads.

current state of some other subvolume. Snapshots clearly have a useful backup function. If, for example, one has a Linux system using Btrfs, one can create a snapshot prior to installing a set of distribution updates. If the updates go well, the snapshot can simply be deleted. Should the update go badly,, instead, the snapshot can be made the default badly subvolume and, after a reboot, everything is as it was before.

(a). Initial state

(b) After Snapshot

Fig. 8. Snapshot of subvolume 'A' (13)

Figure 8 shows BtrFS implementation of snapshot. Snapshot of subvolume A is taken. Since BtrFS is a copy-on-write file fi le system, only reference count of the immediate child, B and D are updated and hence the snapshot with BtrFS is exceptionally fast.

IV.

TEST RESULTS

  There aare re no agreed upon sstandards tandards for testing testing file system . While there are industry benchmarks for the NFS and CIFS protocols, they cover only a small percent of the workloads

Fig. 8. Kernel compilation, all files systems systems exhibit similar performance. (Ohad)

The first test was a Linux kernel make, starting from a clean tree of source files. Tests were run on a single socket 3.2 Ghz quad core x86 processor with 8 gigabytes of ram on a single SATA drive with a 6gb/s link. A block trace was collected, starting with the make -j8 command. This starts eight parallel thr threa eads ds tha thatt perfor perform m C compi compila latio tion n and and linkin linking g wi with th gc gcc. c.

 

Figure 8 compares throughput, seek count, and Iops between the three file systems. Ext4 has slightly higher throughput than BtrFS and XFS, averaging a little less than twice as much throughput. Test results are show in figure 8. Another performance test was Basic File I/O (single instance of FIO) throughput throughput and throughp throughput ut under under high load (multiple (multiple instances of FIO).

and phoronix.com's benchmark benchmark results [8] show that BtrFS was overall winner.

V.

CONCLUSION

Storage systems are not perfect. Faults are inevitable, but expectations for data availability in a mission critical system are extremely high. A silent data corruption can be even more catastrophic. With high volume of data, ubiquitous computing, a file system plays a crucial role in the fault tolerance and performance of storage systems. File systems in the past used Journaling mechanism for metadata, but it is unable to provide data andthe consistency. solve solveintegrity man many y of chall challen enges gesCopy-on-write wit with h storag storagee mechanism fau faults lts,, but can th thee ubiquitous b-tree based file system in it's native form faced severe seve re perf performa ormance nce pena penalties lties.. This problem was solved solved by using COW friendly b-trees and is the basis of BtrFS core design. BtrFS is a relatively young Linux file system. It is based on copy-on-write, and supports efficient snapshots and strong data integrity. As a general purpose files system, BtrFS has to work well on a wide range of hardware. It is still under heavy hea vy devel developm opmen ent. t. It is recomm recommen ended ded to use use tradit tradition ional al backup techniques along with BtrFS deployment. No single solution can provide all benefits, hence a combination of data recovery reco very mechanism mechanism should should be employed employed for storage storage fault tolerance.

Fig. 9. Read operation with single FIO

REFERENCES [1]

BA BAYER, YER,ordered R. AND McC McCREIGH REIGHT, T, E. 1972. 1972. Organizati Org anization on and maintenanc maintenancee of large indices. Acta Informatica, 173–189.

[2] [2]

FORD FORD , D., D., L AB ABEL ELLE LE , F., P OPOV OPOVIC ICII , F., S TO TOKE KEL LY , M. M.,, TRUONG , V., B ARROSO , L., G RIMES , C., AND Q UINLAN , S. Av Availabil ailability ity in globally globally distributed distributed storage systems. In 9th  USENIX Symposium Symposi um on Operating Operating Systems Systems Desig Design n and Implementati Implementation on (Oct 2010)

[3]

Bia Bianca nca Schroed Schroeder er and Garth Garth A. Gibson. Gibson. 2007. Disk Disk failures failures in the real world: what does an MTTF world: MTTF of 1,00 1,000,00 0,000 0 hou hours rs mean mean to you?. In  Proceedings of the 5th USENIX conference conference on File and Storage Technologies (FAST Technologies  (FAST '07). USENIX Association, Berkeley, CA, USA, , Article 1 .

[4]

Andr Andrew ew W. W. Leung, Sha Shankar nkar Pasupat Pasupathy hy,, Garth Goodson Goodson,, and Eth Ethan an L. Miller.. 2008. Measurement and analy Miller analysis sis of large-scal large-scalee network file sy syst stem em workl workloa oads ds.. In USEN USENIX IX 2008 Annu Annual al Techni echnical cal Conf Confere erence nce (ATC'08). (ATC'08). USENIX Association, Berkeley, CA, USA, 213-226. .

[5]

Ohad Ro Rodeh. deh. 2008. 2008. B-tree B-trees, s, shadowi shadowing, ng, and clone clones. s. Trans. Storage 3, Storage 3, 4, Article 2 (February 2008), 27 pages. DOI=10.1145/1326542.1326544 http://doi.acm.org/10.1145/1326542.1326544

[6]

Ohad Ro Rodeh, deh, Josef Josef Bacik Bacik,, and Chris Chris Mason. Mason. 2013. BTRFS BTRFS:: The Lin Linux ux B-Tree B-Tr ee Filesystem. Filesystem. Trans. Storage 9, Storage 9, 3, Article 9 (August 2013), 32 pages.DOI=10.1145/2501620.2501623 http://doi.acm.org/10.1145/2501620.2501623

[7]

events.linuxfo events.linuxfoundatio undation.jp/s n.jp/sites/ ites/events events/files /files/slide /slides/li s/linux_file nux_file_syst _system_ana em_ana lysis_for_IVI_systems.pdf

[8]

htt http:/ p://ww /www w.pho .phoroni ronix.co x.com/s m/scan. can.php php?? page=article&item=linux_315_hddfs&num=3

[9] [9]

Bi Bitr trot ot and at atom omiic COWs: OWs: Ins nsid idee “ne next xt--ge gen” n” fi fillesy esyst stem emss. http://arstechnica.com/information-technology/2014/01/bitrot-andatomic-cows-inside-next-gen-filesystems/1/

Fig. 10. Write operation with single FIO

Evaluation environment was, Intel Desktop Board D510MO, 1GB DDR2-667 PC2-5300 PC2-5300 memo memory ry,, Storage Storage : 32GB Intel X25-E X25E e-SA e-SAT TA SSD, SSD, 64 bit Linux Linux Kenel v3.15.1. v3.15.1. FIO; a software tool for generating different types of I/O was used for benchmarking. With single instance of FIO, BtrFS performed slightly better than Ext4 in sequential read operation. In random read, results were reversed. Ext4 was almost twice Faster than BtrFS for write operation. operation. BtrFS BtrFS performan performance ce degr degradat adation ion under under high load was more graceful than Ext4. BtrFS kernel threads used CPU resource effectively effectively.. There are other use cases as we well ll

[10] https://btrfs https://btrfs.wiki.k .wiki.kernel.o ernel.org/in rg/index.php/ dex.php/Manpag Manpage/btrfs e/btrfs-scrub -scrub [11] http://en.wi http://en.wikipedia kipedia.org/w .org/wiki/De iki/Device_m vice_mapper apper [12] https://btrfs https://btrfs.wiki.k .wiki.kernel.o ernel.org/in rg/index.php/ dex.php/Manpag Manpage/btrfs e/btrfs-subvo -subvolume lume [13] http://www http://www.ibm.com .ibm.com/develo /developerwork perworks/cn/l s/cn/linux/linux/l-cn-btr cn-btrfs/ fs/