注意:

The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.

Difference between revisions of "Btrfs/zh-cn"

From Funtoo
Jump to navigation Jump to search
(Created page with "要在重启后自动挂载这个卷,需要添加一个简单的 fstab 条目:")
(Updating to match new version of source page)
 
(9 intermediate revisions by one other user not shown)
Line 1: Line 1:
<div class="mw-translate-fuzzy">
<languages/>
<languages/>
BTRFS 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 August 2014 the file system's on-disk format has been marked as stable.
BTRFS 是一个基于写时复制 (COW) 原则的文件系统,最初是在 Oracle 公司设计的,用于 Linux。Btrfs 的开发始于 2007 年,自 2014 年 8 月起,该文件系统的磁盘格式被标记为稳定。
</div>


In 2015, Btrfs was adopted as the default filesystem for SUSE Linux Enterprise Server 12. SUSE reaffirmed its commitment to Btrfs in 2017 after RedHat announced to stop supporting Btrfs.
<div class="mw-translate-fuzzy">
2015 年,Btrfs 被采纳为 SUSE Linux Enterprise Server 12 的默认文件系统。在 RedHat 宣布停止支持 Btrfs 后,SUSE 于 2017 年重申了对 Btrfs 的承诺。
</div>


Btrfs 旨在解决 Linux 文件系统中缺乏文件池、快照、校验和以及集成多设备跨度的问题。
Btrfs 旨在解决 Linux 文件系统中缺乏文件池、快照、校验和以及集成多设备跨度的问题。


It is easy to set up and use BTRFS. In this simple introduction, we're going to set up BTRFS under Funtoo Linux using an existing {{c|debian-sources}} or {{c|debian-sources-lts}} kernel, like the one that comes pre-built for you with Funtoo Linux, and we will also be using our BTRFS storage pool for storing data that isn't part of the Funtoo Linux installation itself. Funtoo Linux will boot from a non-BTRFS filesystem, and as part of the initialization process will initialize our BTRFS storage and mount it at the location of our choice.
<div class="mw-translate-fuzzy">
设置和使用 BTRFS 非常简单。在这个简单的介绍中,我们将使用现有的 {{c|debian-sources}} {{c|debian-sources-lts}} 内核在 Funtoo Linux 下设置 BTRFS,比如 Funtoo Linux 为你预置的内核,我们还将使用我们的 BTRFS 存储池来存储不属于 Funtoo Linux 安装本身的数据。Funtoo Linux 将从一个非 BTRFS 文件系统启动,作为初始化过程的一部分,将初始化我们的 BTRFS 存储,并将其挂载在我们选择的位置。
</div>


== 安装 ==
== 安装 ==


<div class="mw-translate-fuzzy">
安装 BTRFS 不需要任何额外的步骤,因为它是 Linux 内核的一部分(从 2.6.29 开始在主线 Linux 内核中)。让我们用 emerge 安装 BTRFS 用户空间工具 ({{c|btrfs-progs}})。
安装 BTRFS 不需要任何额外的步骤,因为它是 Linux 内核的一部分(从 2.6.29 开始在主线 Linux 内核中)。让我们用 emerge 安装 BTRFS 用户空间工具 ({{c|btrfs-progs}})。
</div>


<div class="mw-translate-fuzzy">
{{console|body=
{{console|body=
# ##i##emerge btrfs-progs
# ##i##emerge btrfs-progs
}}
}}
</div>


<div class="mw-translate-fuzzy">
BTRFS 现在可以使用了。
BTRFS 现在可以使用了。
</div>


<div class="mw-translate-fuzzy">
== BTRFS 概念 ==
== BTRFS 概念 ==
</div>


BTRFS can be used to manage the physical disks that it uses, and physical disks are added to a BTRFS volume. Then, BTRFS can create subvolumes from the volume on which files can be stored.
<div class="mw-translate-fuzzy">
BTRFS 可以用来管理它使用的物理磁盘,物理磁盘被添加到 BTRFS 卷中。然后,BTRFS 可以从卷中创建子卷,子卷上可以存储文件。
</div>


与传统的 Linux 文件系统不同,BTRFS 文件系统将从底层卷按需分配存储空间。  
<div class="mw-translate-fuzzy">
与传统的 Linux 文件系统不同,BTRFS 文件系统将从底层卷按需分配存储空间。
</div>


<div class="mw-translate-fuzzy">
在 BTRFS 的世界里,卷这个词对应的是一个存储池 (ZFS) 或一个卷组 (LVM)。
在 BTRFS 的世界里,卷这个词对应的是一个存储池 (ZFS) 或一个卷组 (LVM)。
</div>


* ''devices'' - one or multiple underlying physical volumes.
* ''设备'' - 一个或多个底层物理卷。
* ''volume'' - one large storage pool comprised of all space of the devices and can support different redundancy levels
* '''' - 一个大型存储池,由设备的所有空间组成,可支持不同的冗余级别。
* ''subvolumes'' - these are what get mounted and you store files in.
* ''子卷'' - 这些是被挂载的部分,你可以在其中存储文件。
* ''snapshots'' - a read-only copy of a subvolume at a given point in time and/or read-write copy of a ''subvolume'' in time (aka clone).
* ''快照'' - 子卷在某个时间点的只读副本和/''子卷''在某个时间点的读写副本(也就是克隆)。


== 创建一个卷 ==
== 创建一个卷 ==


<div class="mw-translate-fuzzy">
要创建一个基本的 BTRFS 卷,将需要一个额外的空盘。执行以下步骤:
要创建一个基本的 BTRFS 卷,将需要一个额外的空盘。执行以下步骤:
</div>


{{console|body=
{{console|body=
Line 68: Line 90:


{{console|body=
{{console|body=
# ##i## mkdir /mnt/btrfs-top-level
# ##i## mount /dev/sdxy /mnt/btrfs-top-level
# ##i## mount
...
/dev/sdxy on /mnt/btrfs-top-level type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
}}
{{Important|It is recommended that nothing is stored directly on this top-level volume (ID 5) root directory.}}
== Creating Subvolumes ==
Btrfs has a concept of subvolumes. Subvolume is an independently mountable POSIX filetree (but not a block device). There are several basic schemas to layout subvolumes (including snapshots) as well as mixtures thereof.
Lets create children of the top level subvolume (ID 5). We will have:
* {{c|@data}} - it will serve as mountable {{c|/data}}
* {{c|.snapshots}} - here snapshots will be stored
{{console|body=
# ##i## cd /mnt/btrfs-top-level
# ##i## btrfs subvolume create @data
# ##i## btrfs subvolume create .snapshots
# ##i## btrfs subvolume list /mnt/btrfs-top-level
ID 256 gen 322338 top level 5 path @data
ID 257 gen 322275 top level 5 path .snapshots
}}
== The default Subvolume ==
{{Note|Changing the default subvolume with {{c|btrfs subvolume default}} will make the top level of the filesystem accessible only when {{c|subvol}} or {{c|subvolid}} mount options are specified}}
When btrfs block device is mounted without specifying a subvolume the default one is used. To check default subvolume run
{{console|body=
# ##i## btrfs subvolume get-default /mnt/btrfs-top-level
ID 5 (FS_TREE)
}}
For the convenience lets make {{c|@data}} subvolume as the default one. It's good to double check the subvolume ID first. Either {{c|btrfs subvolume list}} or {{c|btrfs subvolume show}} can be used for that
{{console|body=
# ##i## btrfs subvolume show /mnt/btrfs-top-level/@data
...
Subvolume ID: 256
}}
Now you can make this subvolume as a default one
{{console|body=
# ##i## btrfs subvolume set-default 256 /mnt/btrfs-top-level
# ##i## btrfs subvolume get-default /mnt/btrfs-top-level
ID 256 gen 322336 top level 5 path @data
}}
At this point you can stop working on the top level subvolume (ID 5) and instead mount directly {{c|@data}} subvolume.
{{console|body=
# ##i## cd /mnt
# ##i## umount /mnt/btrfs-top-level
# ##i## mkdir /data
# ##i## mkdir /data
# ##i## mount /dev/sdxy /data
# ##i## mount /dev/sdxy /data
# ##i## mount
...
/dev/sdxy on /data type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
}}
}}


要在重启后自动挂载这个卷,需要添加一个简单的 fstab 条目:
== Nested Subvolumes ==
 
{{Note|Nested subvolumes are not going to be a part of snapshots created from their parent subvolume. So one typical reason is to exclude certain parts of the filesystem from being snapshot.}}
 
Lets create a separate nested subvolume for {{c|/data/independent}}.
 
{{console|body=
# ##i## btrfs subvolume create /data/independent
# ##i## btrfs subvolume list /data
ID 258 gen 161 top level 256 path independent
}}
 
Usually you will want to "split" areas which are "complete" and/or "consistent" in themselves. Examples for this more-fine grained partitioning could be {{c|/var/log}}, {{c|/var/www}} or {{c|/var/lib/postgresql}}.
 
== /etc/fstab ==
 
To automatically mount the {{c|@data}} subvolume after reboot you need to modify {{c|/etc/fstab}}
 
{{file|name=/etc/fstab|desc=fstab for btrfs|body=
/dev/sdxy /data btrfs subvolid=256,defaults 0 0
}}
 
{{Warning|According to [https://btrfs.readthedocs.io/en/latest/Administration.html#mount-options btrfs docs] most mount options apply to the whole filesystem and only options in the first mounted subvolume will take effect. This means that (for example) you can't set per-subvolume {{c|nodatacow}}, {{c|nodatasum}}, or {{c|compress}}.}}
 
Now lets verify if this changes were correct
{{console|body=
# ##i## cd /
# ##i## umount /data
# ##i## mount /data
# ##i## ls /data
independent
}}
 
Did you just notice that although we mounted our {{c|@data}} subvolume the nested subvolume {{c|@data/independent}} is also present?
 
== Snapshots ==
 
For the purpose of checking out this cool btrfs feature lets populate our filesystem with some example data first
 
{{console|body=
# ##i## echo 'btrfs' > /data/foo.txt
# ##i## echo 'fun' > /data/independent/bar.txt
}}
 
As you probably remember on the top level (next to {{c|@data}} subvolume) you've also created the {{c|.snapshots}} subvolume. You can mount it now to create some snapshots
{{console|body=
# ##i## mkdir /mnt/snapshots
# ##i## mount /dev/sdxy /mnt/snapshots -o subvolid=257
}}
 
A snapshot is a subvolume like any other, with given initial content. By default, snapshots are created read-write. File modifications in a snapshot do not affect the files in the original subvolume. Lets create a read-write snapshot for {{c|/data}} and read-only snapshot for {{c|/data/independent}}
 
{{console|body=
# ##i## btrfs subvolume snapshot /data /mnt/snapshots/data_$(date -u -Iseconds)
Create a snapshot of '/data' in '/mnt/snapshots/data_2022-08-30T22:04:57+00:00'
# ##i## btrfs subvolume snapshot -r /data/independent /mnt/snapshots/independent_$(date -u -Iseconds)
Create a readonly snapshot of '/data/independent' in '/mnt/snapshots/independent_2022-08-30T22:05:29+00:00'
}}
 
Once again, nested subvolumes are not going to be a part of snapshots created from their parent subvolume. So you shouldn't be surprised when you compare the contents of the {{c|/data}} vs the contents of the {{c|/mnt/snapshots}}
 
{{console|body=
# ##i## tree /data
/data
├── foo.txt
└── independent
    └── bar.txt
# ##i## tree /mnt/snapshots
/mnt/snapshots
├── data_2022-08-30T22:04:57+00:00
│   └── foo.txt
└── independent_2022-08-30T22:05:29+00:00
    └── bar.txt
}}
 
At this point you might be interested in [https://btrfs.readthedocs.io/en/latest/Send-receive.html send and receive btrfs features].
 
{{Note|According to [https://btrfs.readthedocs.io/en/latest/Subvolumes.html btrfs docs] a snapshot is not a backup: snapshots work by use of BTRFS copy-on-write behaviour. A snapshot and the original it was taken from initially share all of the same data blocks. If that data is damaged in some way (cosmic rays, bad disk sector, accident with dd to the disk), then the snapshot and the original will both be damaged.}}
 
== Wrap up ==
 
{{Important|It is recommended to run {{c|btrfs scrub}} once in a while. E.g. every month}}
 
Scrub is the online check and repair functionality that verifies the integrity of data and metadata, assuming the tree structure is fine. You can run it on a mounted file system; it runs as a background process during normal operation.
 
To start a (background) scrub on the filesystem which contains {{c|/data}} run
 
{{console|body=
# ##i## btrfs scrub start /data
scrub started on /data, fsid 40f8b94f-07ee-4f7e-beb1-8e686abc246d (pid=5525)
}}
 
To check the status of a running scrub


{{console|body=
{{console|body=
/dev/sdxy /data btrfs defaults 0 0
# ##i## btrfs scrub status /data
UUID:            40f8b94f-07ee-4f7e-beb1-8e686abc246d
Scrub started:    Tue Aug 30 00:38:54 2022
Status:          running
Duration:        0:00:15
Time left:        0:00:34
ETA:              Tue Aug 30 00:39:44 2022
Total to scrub:  149.06GiB
Bytes scrubbed:  44.79GiB  (30.04%)
Rate:            2.99GiB/s
Error summary:    no errors found
}}
}}


You should now be at the point where you can begin to use BTRFS for a variety of tasks. While there is a lot more to BTRFS than what is covered in this short introduction, you should now have a good understanding of the fundamental concepts on which BTRFS is based.
<div class="mw-translate-fuzzy">
你现在应该已经到了可以开始使用 BTRFS 来完成各种任务的阶段。虽然 BTRFS 的内容比这篇简短的介绍要多得多,但你现在应该对 BTRFS 的基本概念有了很好的理解。
</div>


<div class="mw-translate-fuzzy">
[[Category:BTRFS]]
[[Category:BTRFS]]
[[Category:Filesystems]]
[[Category:Filesystems]]
[[Category:HOWTO]]
[[Category:HOWTO]]
[[Category:Official Documentation]]
[[Category:Official Documentation]]
</div>

Latest revision as of 18:14, September 4, 2022

Other languages:
English • ‎Türkçe • ‎español • ‎português do Brasil • ‎中文(中国大陆)‎

BTRFS 是一个基于写时复制 (COW) 原则的文件系统,最初是在 Oracle 公司设计的,用于 Linux。Btrfs 的开发始于 2007 年,自 2014 年 8 月起,该文件系统的磁盘格式被标记为稳定。

2015 年,Btrfs 被采纳为 SUSE Linux Enterprise Server 12 的默认文件系统。在 RedHat 宣布停止支持 Btrfs 后,SUSE 于 2017 年重申了对 Btrfs 的承诺。

Btrfs 旨在解决 Linux 文件系统中缺乏文件池、快照、校验和以及集成多设备跨度的问题。

设置和使用 BTRFS 非常简单。在这个简单的介绍中,我们将使用现有的 debian-sourcesdebian-sources-lts 内核在 Funtoo Linux 下设置 BTRFS,比如 Funtoo Linux 为你预置的内核,我们还将使用我们的 BTRFS 存储池来存储不属于 Funtoo Linux 安装本身的数据。Funtoo Linux 将从一个非 BTRFS 文件系统启动,作为初始化过程的一部分,将初始化我们的 BTRFS 存储,并将其挂载在我们选择的位置。

安装

安装 BTRFS 不需要任何额外的步骤,因为它是 Linux 内核的一部分(从 2.6.29 开始在主线 Linux 内核中)。让我们用 emerge 安装 BTRFS 用户空间工具 (btrfs-progs)。

root # emerge btrfs-progs

BTRFS 现在可以使用了。

BTRFS 概念

BTRFS 可以用来管理它使用的物理磁盘,物理磁盘被添加到 BTRFS 卷中。然后,BTRFS 可以从卷中创建子卷,子卷上可以存储文件。

与传统的 Linux 文件系统不同,BTRFS 文件系统将从底层卷按需分配存储空间。

在 BTRFS 的世界里,卷这个词对应的是一个存储池 (ZFS) 或一个卷组 (LVM)。

  • 设备 - 一个或多个底层物理卷。
  • - 一个大型存储池,由设备的所有空间组成,可支持不同的冗余级别。
  • 子卷 - 这些是被挂载的部分,你可以在其中存储文件。
  • 快照 - 子卷在某个时间点的只读副本和/或子卷在某个时间点的读写副本(也就是克隆)。

创建一个卷

要创建一个基本的 BTRFS 卷,将需要一个额外的空盘。执行以下步骤:

root #  mkfs.btrfs /dev/sdxy
btrfs-progs v4.17.1 
See http://btrfs.wiki.kernel.org for more information.

Detected a SSD, turning off metadata duplication.  Mkfs with -m dup if you want to force metadata duplication.
Performing full device TRIM /dev/sdj (223.57GiB) ...
Label:              (null)
UUID:               d6bcba6e-8fd5-41fc-9bb4-79628c5c928c
Node size:          16384
Sector size:        4096
Filesystem size:    223.57GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         single            8.00MiB
  System:           single            4.00MiB
SSD detected:       yes
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1   223.57GiB  /dev/sdxy

/dev/sdxy 应该是一个未使用的磁盘。如果这个磁盘上有任何已存在的数据,可能需要使用以下命令:

root #  mkfs.btrfs -f /dev/sdxy

现在可以像挂载其他 linux 文件系统一样挂载所创建的卷。

root #  mkdir /mnt/btrfs-top-level
root #  mount /dev/sdxy /mnt/btrfs-top-level
root #  mount
...
/dev/sdxy on /mnt/btrfs-top-level type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
   Important

It is recommended that nothing is stored directly on this top-level volume (ID 5) root directory.

Creating Subvolumes

Btrfs has a concept of subvolumes. Subvolume is an independently mountable POSIX filetree (but not a block device). There are several basic schemas to layout subvolumes (including snapshots) as well as mixtures thereof.

Lets create children of the top level subvolume (ID 5). We will have:

  • @data - it will serve as mountable /data
  • .snapshots - here snapshots will be stored
root #  cd /mnt/btrfs-top-level
root #  btrfs subvolume create @data
root #  btrfs subvolume create .snapshots
root #  btrfs subvolume list /mnt/btrfs-top-level
ID 256 gen 322338 top level 5 path @data
ID 257 gen 322275 top level 5 path .snapshots

The default Subvolume

   Note

Changing the default subvolume with btrfs subvolume default will make the top level of the filesystem accessible only when subvol or subvolid mount options are specified

When btrfs block device is mounted without specifying a subvolume the default one is used. To check default subvolume run

root #  btrfs subvolume get-default /mnt/btrfs-top-level
ID 5 (FS_TREE)

For the convenience lets make @data subvolume as the default one. It's good to double check the subvolume ID first. Either btrfs subvolume list or btrfs subvolume show can be used for that

root #  btrfs subvolume show /mnt/btrfs-top-level/@data
...
	Subvolume ID: 		256

Now you can make this subvolume as a default one

root #  btrfs subvolume set-default 256 /mnt/btrfs-top-level
root #  btrfs subvolume get-default /mnt/btrfs-top-level
ID 256 gen 322336 top level 5 path @data

At this point you can stop working on the top level subvolume (ID 5) and instead mount directly @data subvolume.

root #  cd /mnt
root #  umount /mnt/btrfs-top-level
root #  mkdir /data
root #  mount /dev/sdxy /data

Nested Subvolumes

   Note

Nested subvolumes are not going to be a part of snapshots created from their parent subvolume. So one typical reason is to exclude certain parts of the filesystem from being snapshot.

Lets create a separate nested subvolume for /data/independent.

root #  btrfs subvolume create /data/independent
root #  btrfs subvolume list /data
ID 258 gen 161 top level 256 path independent

Usually you will want to "split" areas which are "complete" and/or "consistent" in themselves. Examples for this more-fine grained partitioning could be /var/log, /var/www or /var/lib/postgresql.

/etc/fstab

To automatically mount the @data subvolume after reboot you need to modify /etc/fstab

   /etc/fstab - fstab for btrfs
/dev/sdxy	/data	btrfs	subvolid=256,defaults	0 0
   Warning

According to btrfs docs most mount options apply to the whole filesystem and only options in the first mounted subvolume will take effect. This means that (for example) you can't set per-subvolume nodatacow, nodatasum, or compress.

Now lets verify if this changes were correct

root #  cd /
root #  umount /data
root #  mount /data
root #  ls /data
independent

Did you just notice that although we mounted our @data subvolume the nested subvolume @data/independent is also present?

Snapshots

For the purpose of checking out this cool btrfs feature lets populate our filesystem with some example data first

root #  echo 'btrfs' > /data/foo.txt
root #  echo 'fun' > /data/independent/bar.txt

As you probably remember on the top level (next to @data subvolume) you've also created the .snapshots subvolume. You can mount it now to create some snapshots

root #  mkdir /mnt/snapshots
root #  mount /dev/sdxy /mnt/snapshots -o subvolid=257

A snapshot is a subvolume like any other, with given initial content. By default, snapshots are created read-write. File modifications in a snapshot do not affect the files in the original subvolume. Lets create a read-write snapshot for /data and read-only snapshot for /data/independent

root #  btrfs subvolume snapshot /data /mnt/snapshots/data_$(date -u -Iseconds)
Create a snapshot of '/data' in '/mnt/snapshots/data_2022-08-30T22:04:57+00:00'
root #  btrfs subvolume snapshot -r /data/independent /mnt/snapshots/independent_$(date -u -Iseconds)
Create a readonly snapshot of '/data/independent' in '/mnt/snapshots/independent_2022-08-30T22:05:29+00:00'

Once again, nested subvolumes are not going to be a part of snapshots created from their parent subvolume. So you shouldn't be surprised when you compare the contents of the /data vs the contents of the /mnt/snapshots

root #  tree /data
/data
├── foo.txt
└── independent
    └── bar.txt
root #  tree /mnt/snapshots
/mnt/snapshots
├── data_2022-08-30T22:04:57+00:00
│   └── foo.txt
└── independent_2022-08-30T22:05:29+00:00
    └── bar.txt

At this point you might be interested in send and receive btrfs features.

   Note

According to btrfs docs a snapshot is not a backup: snapshots work by use of BTRFS copy-on-write behaviour. A snapshot and the original it was taken from initially share all of the same data blocks. If that data is damaged in some way (cosmic rays, bad disk sector, accident with dd to the disk), then the snapshot and the original will both be damaged.

Wrap up

   Important

It is recommended to run btrfs scrub once in a while. E.g. every month

Scrub is the online check and repair functionality that verifies the integrity of data and metadata, assuming the tree structure is fine. You can run it on a mounted file system; it runs as a background process during normal operation.

To start a (background) scrub on the filesystem which contains /data run

root #  btrfs scrub start /data
scrub started on /data, fsid 40f8b94f-07ee-4f7e-beb1-8e686abc246d (pid=5525)

To check the status of a running scrub

root #  btrfs scrub status /data
UUID:             40f8b94f-07ee-4f7e-beb1-8e686abc246d
Scrub started:    Tue Aug 30 00:38:54 2022
Status:           running
Duration:         0:00:15
Time left:        0:00:34
ETA:              Tue Aug 30 00:39:44 2022
Total to scrub:   149.06GiB
Bytes scrubbed:   44.79GiB  (30.04%)
Rate:             2.99GiB/s
Error summary:    no errors found

你现在应该已经到了可以开始使用 BTRFS 来完成各种任务的阶段。虽然 BTRFS 的内容比这篇简短的介绍要多得多,但你现在应该对 BTRFS 的基本概念有了很好的理解。