translator
1,001
edits
(created, but not linked to) |
(basis for future extension) |
||
Line 2: | Line 2: | ||
<!-- TOC shows contents of the page -->__TOC__ | <!-- TOC shows contents of the page -->__TOC__ | ||
[[File:Page Under Construction.jpg|thumb|center|Page under construction]] | |||
<!-- Example titles --> | <!-- Example titles --> | ||
=btrfs is a modern CoW file system= | |||
A modern '''C'''opy '''o'''n '''W'''rite file system for Linux aimed at implementing advanced features while also focusing on '''fault tolerance''', '''repair''' and '''easy administration'''. Btrfs not only is a file system, but also is partly a volume manager, software-raid, backup-tool, and it is flash-friendly. | A modern '''C'''opy '''o'''n '''W'''rite file system for Linux aimed at implementing advanced features while also focusing on '''fault tolerance''', '''repair''' and '''easy administration'''. Btrfs not only is a file system, but also is partly a volume manager, software-raid, backup-tool, and it is flash-friendly. | ||
Line 13: | Line 14: | ||
*'''Self-healing''' - checksums for data and metadata, automatic detection of silent data corruptionssee [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs@kernel.org], [https://wiki.archlinux.org/title/Btrfs Btrfs@ARC-wiki], [https://de.wikipedia.org/wiki/Btrfs Btrfs@wikipedia] | *'''Self-healing''' - checksums for data and metadata, automatic detection of silent data corruptionssee [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs@kernel.org], [https://wiki.archlinux.org/title/Btrfs Btrfs@ARC-wiki], [https://de.wikipedia.org/wiki/Btrfs Btrfs@wikipedia] | ||
=== | === why not btrfs ? === | ||
A lot of people say: "'''I don't use btrfs because''' it is experimental and is '''not stable'''. You can´t use it in production. It is not save!". | |||
==== not stable ? ==== | |||
Sure this is partly right. But please look for the date of such statements. Some seem to date from 10 years ago. So if you want to give btrfs a chance, you have to look for newer statements. Maybe even look at btrfs.wiki.kernel.org sure there is the best information regarding btrfs | |||
==== experimental ? ==== | |||
Btrfs is feature-rich! And there are some features that are '''not implemented yet'''. Others are only '''partly implemented'''. Some are '''experimental''' and not suggested for production use. And as in linux general YOU decide what to use, and so you are responsible for your own decisions. | |||
==== not usable for production ? ==== | |||
* Some linux distributions do support btrfs as main file system | |||
* Some firms do use btrfs in production@wiki.btrfs.kernel.org | |||
* Some manufactorers do deploy devices where btrfs is used inside | |||
==== difficult to repair ? ==== | |||
Indeed when you search for the usual ways to repair a file system like FAT or Ext4 then you don't find good information. But this is not because it is difficult to repair btrfs, but because repairing btrfs '''does work very different'''. | |||
== What's this "Copy on Write" == | |||
When you want to get the most out of using btrfs you do need to know some things about this file system. Then you are able to use it properly and to your advantage. btrfs is not difficult,l but different to some extend. | |||
=== write in place (FAT32) === | |||
Most file systems did write "in place". This means that some data or metadata will be written "over" the previous data at the same place. | |||
For example this is the case for FAT32 file systems. The '''F'''ile '''A'''llocation '''T'''able is at a fixed place on this file system. When the "FAT" changes (because a file got bigger and needs more blocks), this new FAT must be written with the new data to the same place as bevor. When the disk is ejected bevor(or while) this data is written, the file system will be corrupted. And the FAT does change a lot. | |||
The danger of corruption is especially big when metadata (like filename, permission, usage of disk space ...) is written. | |||
=== write to a metadata-log (Ext4) === | |||
There is a solution to this with newer file systems like Ext4. Instead of writing metadata "in place", metadata is written into an "endless" log. Then it is not possible to be corrupted while overwritten. This is possible because metadata is only a very small part of the data in a file system. | |||
There has to be an additional mechanism to make this save. Sometimes it is called barriers. And there have to be checksums that tell when a part of the log is corrupted. | |||
This does protect the file system itself, but not the files in it. Because a file may be overwritten in place, and then the old file is lost, and the new one may not have been written completely. | |||
=== copy on write! (btrfs)=== | |||
Copy on write is a "new" concept. This means the file system will try to '''never''' write over existing data. '''How is this possible?''' | |||
* Files are appended at the end of a "data page" | |||
* Metadata is appended at a "metadata page" | |||
* Inside a page nothing is ever overwritten | |||
* When a page is full the file system will use the next free page | |||
* Deleting a file does not write/clean its data, but writes metadata, that marks this file as deleted | |||
* Overwriting a file does first append the new file to the "data page", then writes the metadata for this file | |||
* there are checksums for data and metadata | |||
==== downsides ==== | |||
* management of space is complex | |||
* there are 2 sorts of pages | |||
* there has to be a cleanup-process who makes the space of deleted files reusable, so that the disk does not run out of free pages | |||
* it must be avoided to write data unnecessarily, because then the cleanup would also be very expensive | |||
==== chances ==== | |||
* it is possible to detect nearly any corruption because of the checksums | |||
** when the power is lost, or the disk is disconnected, all old data is save. WHY? | |||
** every bit of "old" data from bevor the power loss or the disconnection is present because it is NOT overwritten | |||
** only the newly written data may be partly damaged | |||
** the metadata may also be partly damaged | |||
** when mounting the volume it is possible by analyzing checksums and metadata to find the point in the file system where all was good | |||
** btrfs will automatically roll back to this point, then it can mount the file system writeable | |||
* CoW is a sound foundation to build upon | |||
** snapshots | |||
** RAID | |||
** volume management | |||
** compression | |||
** encryption (maybe some time in the future) | |||
<!-- If you use command, it should be inside of usercmd. You can see below example --> | |||
{{UserCmd|command=example command should be here}} | {{UserCmd|command=example command should be here}} | ||
Line 23: | Line 92: | ||
<!-- Don't forget to look more templates: https://wiki.manjaro.org/index.php/Help:Template --> | <!-- Don't forget to look more templates: https://wiki.manjaro.org/index.php/Help:Template --> | ||
<small>Please be aware that the information on this page is a simplified version of the reality. Is is written to make the reader understand a little of these complex things. To get an in depth understanding it will be neccesary to read further at btrfs.wiki.kernel.org or other places.</small> | |||
=See Also= | =See Also= |