The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Difference between revisions of "Btrfs/pt-br"
(Created page with "Agora você deve estar no ponto em que pode começar a usar o BTRFS para uma variedade de tarefas. Embora exista muito mais no BTRFS do que o que é abordado nesta breve intro...") |
(Updating to match new version of source page) |
||
Line 1: | Line 1: | ||
<div class="mw-translate-fuzzy"> | |||
<languages/> | <languages/> | ||
O BTRFS é um sistema de arquivos baseado no princípio de cópia na gravação (COW), inicialmente projetado na Oracle Corporation para uso no Linux. O desenvolvimento do Btrfs começou em 2007 e, desde agosto de 2014, o formato em disco do sistema de arquivos foi marcado como estável. | O BTRFS é um sistema de arquivos baseado no princípio de cópia na gravação (COW), inicialmente projetado na Oracle Corporation para uso no Linux. O desenvolvimento do Btrfs começou em 2007 e, desde agosto de 2014, o formato em disco do sistema de arquivos foi marcado como estável. | ||
</div> | |||
<div class="mw-translate-fuzzy"> | |||
Em 2015, o Btrfs foi adotado como o sistema de arquivos padrão para o SUSE Linux Enterprise Server 12. O SUSE reafirmou seu compromisso com o Btrfs em 2017, depois que a RedHat anunciou que deixaria de oferecer suporte ao Btrfs. | Em 2015, o Btrfs foi adotado como o sistema de arquivos padrão para o SUSE Linux Enterprise Server 12. O SUSE reafirmou seu compromisso com o Btrfs em 2017, depois que a RedHat anunciou que deixaria de oferecer suporte ao Btrfs. | ||
</div> | |||
O Btrfs destina-se a solucionar a falta de pool, instantâneos, somas de verificação e abrangência de vários dispositivos integral nos sistemas de arquivos Linux. | O Btrfs destina-se a solucionar a falta de pool, instantâneos, somas de verificação e abrangência de vários dispositivos integral nos sistemas de arquivos Linux. | ||
<div class="mw-translate-fuzzy"> | |||
É fácil de configurar e usar o BTRFS. Nesta introdução simples, vamos configurar o BTRFS no Funtoo Linux usando um kernel {{c | debian-sources}} ou {{c | debian-sources-lts}} existente, como o que vem pré-compilado para você com o Funtoo Linux, e também usaremos nosso pool de armazenamento BTRFS para armazenar dados que não fazem parte da instalação do Funtoo Linux. O Funtoo Linux inicializa a partir de um sistema de arquivos não-BTRFS e, como parte do processo de inicialização, inicializa nosso armazenamento BTRFS e o monta no local de nossa escolha. | É fácil de configurar e usar o BTRFS. Nesta introdução simples, vamos configurar o BTRFS no Funtoo Linux usando um kernel {{c | debian-sources}} ou {{c | debian-sources-lts}} existente, como o que vem pré-compilado para você com o Funtoo Linux, e também usaremos nosso pool de armazenamento BTRFS para armazenar dados que não fazem parte da instalação do Funtoo Linux. O Funtoo Linux inicializa a partir de um sistema de arquivos não-BTRFS e, como parte do processo de inicialização, inicializa nosso armazenamento BTRFS e o monta no local de nossa escolha. | ||
</div> | |||
== Instalação== | == Instalação== | ||
<div class="mw-translate-fuzzy"> | |||
Para instalar o BTRFS, nenhuma etapa adicional é necessária, pois ele faz parte do Linux Kernel (desde 2.6.29). Vamos emergir as ferramentas de espaço de usuário do BTRFS ({{c | btrfs-progs}}): | Para instalar o BTRFS, nenhuma etapa adicional é necessária, pois ele faz parte do Linux Kernel (desde 2.6.29). Vamos emergir as ferramentas de espaço de usuário do 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"> | |||
Agora o BTRFS está pronto para uso. | Agora o BTRFS está pronto para uso. | ||
</div> | |||
<div class="mw-translate-fuzzy"> | |||
== Conceitos do BTRFS == | == Conceitos do BTRFS == | ||
</div> | |||
O BTRFS pode ser usado para gerenciar os discos físicos que ele usa, e os discos físicos são adicionados a um volume BTRFS. Em seguida, o BTRFS pode criar subvolumes a partir do volume no qual os arquivos podem ser armazenados. | <div class="mw-translate-fuzzy"> | ||
O BTRFS pode ser usado para gerenciar os discos físicos que ele usa, e os discos físicos são adicionados a um volume BTRFS. Em seguida, o BTRFS pode criar subvolumes a partir do volume no qual os arquivos podem ser armazenados. | |||
</div> | |||
Diferente dos sistemas de arquivos Linux tradicionais, os sistemas de arquivos BTRFS alocam armazenamento sob demanda do volume subjacente. | <div class="mw-translate-fuzzy"> | ||
Diferente dos sistemas de arquivos Linux tradicionais, os sistemas de arquivos BTRFS alocam armazenamento sob demanda do volume subjacente. | |||
</div> | |||
<div class="mw-translate-fuzzy"> | |||
No mundo do BTRFS, a palavra volume corresponde a um pool de armazenamento (ZFS) ou a um grupo de volumes (LVM). | No mundo do BTRFS, a palavra volume corresponde a um pool de armazenamento (ZFS) ou a um grupo de volumes (LVM). | ||
</div> | |||
* '' devices '' - um ou vários volumes físicos subjacentes. | * '' devices '' - um ou vários volumes físicos subjacentes. | ||
Line 33: | Line 53: | ||
== Criando um Volume == | == Criando um Volume == | ||
<div class="mw-translate-fuzzy"> | |||
Para criar um volume BTRFS básico, você precisará de um disco vazio extra. Execute as seguintes etapas: | Para criar um volume BTRFS básico, você precisará de um disco vazio extra. Execute as seguintes etapas: | ||
</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 | ||
}} | }} | ||
== 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= | ||
# ##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 | |||
}} | }} | ||
<div class="mw-translate-fuzzy"> | |||
Agora você deve estar no ponto em que pode começar a usar o BTRFS para uma variedade de tarefas. Embora exista muito mais no BTRFS do que o que é abordado nesta breve introdução, agora você deve ter um bom entendimento dos conceitos fundamentais nos quais o BTRFS se baseia. | Agora você deve estar no ponto em que pode começar a usar o BTRFS para uma variedade de tarefas. Embora exista muito mais no BTRFS do que o que é abordado nesta breve introdução, agora você deve ter um bom entendimento dos conceitos fundamentais nos quais o BTRFS se baseia. | ||
</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> |
Revision as of 18:14, September 4, 2022
O BTRFS é um sistema de arquivos baseado no princípio de cópia na gravação (COW), inicialmente projetado na Oracle Corporation para uso no Linux. O desenvolvimento do Btrfs começou em 2007 e, desde agosto de 2014, o formato em disco do sistema de arquivos foi marcado como estável.
Em 2015, o Btrfs foi adotado como o sistema de arquivos padrão para o SUSE Linux Enterprise Server 12. O SUSE reafirmou seu compromisso com o Btrfs em 2017, depois que a RedHat anunciou que deixaria de oferecer suporte ao Btrfs.
O Btrfs destina-se a solucionar a falta de pool, instantâneos, somas de verificação e abrangência de vários dispositivos integral nos sistemas de arquivos Linux.
É fácil de configurar e usar o BTRFS. Nesta introdução simples, vamos configurar o BTRFS no Funtoo Linux usando um kernel debian-sources
ou debian-sources-lts
existente, como o que vem pré-compilado para você com o Funtoo Linux, e também usaremos nosso pool de armazenamento BTRFS para armazenar dados que não fazem parte da instalação do Funtoo Linux. O Funtoo Linux inicializa a partir de um sistema de arquivos não-BTRFS e, como parte do processo de inicialização, inicializa nosso armazenamento BTRFS e o monta no local de nossa escolha.
Instalação
Para instalar o BTRFS, nenhuma etapa adicional é necessária, pois ele faz parte do Linux Kernel (desde 2.6.29). Vamos emergir as ferramentas de espaço de usuário do BTRFS ( btrfs-progs
):
root # emerge btrfs-progs
Agora o BTRFS está pronto para uso.
Conceitos do BTRFS
O BTRFS pode ser usado para gerenciar os discos físicos que ele usa, e os discos físicos são adicionados a um volume BTRFS. Em seguida, o BTRFS pode criar subvolumes a partir do volume no qual os arquivos podem ser armazenados.
Diferente dos sistemas de arquivos Linux tradicionais, os sistemas de arquivos BTRFS alocam armazenamento sob demanda do volume subjacente.
No mundo do BTRFS, a palavra volume corresponde a um pool de armazenamento (ZFS) ou a um grupo de volumes (LVM).
- devices - um ou vários volumes físicos subjacentes.
- volume - um grande conjunto de armazenamentos composto por todo o espaço dos dispositivos e pode suportar diferentes níveis de redundância.
- subvolumes - é isso que é montado e você armazena arquivos.
- snapshots - uma cópia somente leitura de um subvolume em um determinado momento e / ou a cópia de leitura e gravação de um subvolume em tempo de execução (também conhecido como clone).
Criando um Volume
Para criar um volume BTRFS básico, você precisará de um disco vazio extra. Execute as seguintes etapas:
root # mkfs.btrfs /dev/sdxy btrfs-progs v4.17.1 Veja http://btrfs.wiki.kernel.org para mais informações. 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
deve ser um disco não utilizado. Pode ser necessário usar o seguinte comando se este disco contiver dados pré-existentes:
root # mkfs.btrfs -f /dev/sdxy
Agora você pode montar o volume criado como qualquer outro sistema de arquivos 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=/)
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
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
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
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.
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
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
Agora você deve estar no ponto em que pode começar a usar o BTRFS para uma variedade de tarefas. Embora exista muito mais no BTRFS do que o que é abordado nesta breve introdução, agora você deve ter um bom entendimento dos conceitos fundamentais nos quais o BTRFS se baseia.