The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Btrfs/pt-br
Btrfs é um sistema de arquivos baseado no princípio copy-on-write (COW), inicialmente projetado na Oracle Corporation para uso em 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 projeto Funtoo Linux recomenda o btrfs como um sistema de arquivos de última geração, especialmente para uso em produção.
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é-construído para você com o Funtoo Linux, e também usaremos nosso pool de armazenamento btrfs para armazenar dados que não fazem parte da própria instalação do Funtoo Linux. O Funtoo Linux inicializará a partir de um sistema de arquivos não-btrfs e, como parte do processo de inicialização, inicializará nosso armazenamento btrfs e o montará no local de nossa escolha.
Instalação
Habilitar o suporte btrfs é tão simples quanto habilitar o mix-in btrfs e executar uma atualização completa:
root # epro mix-in +btrfs root # emerge -uDN @world
Btrfs agora 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 do volume no qual os arquivos podem ser armazenados.
Ao contrário dos sistemas de arquivos Linux tradicionais, os sistemas de arquivos btrfs alocarão armazenamento sob demanda do volume subjacente.
No mundo 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 os seguintes passos:
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
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=/)
Recomenda-se que nada seja armazenado diretamente neste diretório raiz do volume de nível superior (ID 5).
Criando Subvolumes
Btrfs tem um conceito de subvolumes. Subvolume é uma árvore de arquivos POSIX montável independentemente (mas não um dispositivo de bloco). Existem vários esquemas básicos para layout de subvolumes (incluindo instantâneos), bem como suas misturas.
Vamos criar filhos do subvolume de nível superior (ID 5). Nós teremos:
@data
- servirá como montável/data
.snapshots
- aqui os instantâneos serão armazenados
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
O Subvolume Padrão
Alterar o subvolume padrão combtrfs subvolume default
tornará o nível superior do sistema de arquivos acessível somente quando as opções de montagemsubvol
ousubvolid
forem especificadas
Quando o dispositivo de bloco btrfs é montado sem especificar um subvolume, o padrão é usado. Para verificar o subvolume padrão, execute:
root # btrfs subvolume get-default /mnt/btrfs-top-level ID 5 (FS_TREE)
Por conveniência, vamos tornar o subvolume @data
como o padrão. É bom verificar primeiro o ID do subvolume. Ou btrfs subvolume list
ou btrfs subvolume show
pode ser usado para isso
root # btrfs subvolume show /mnt/btrfs-top-level/@data ... Subvolume ID: 256
Agora você pode tornar este subvolume como padrão:
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
Neste ponto, você pode parar de trabalhar no subvolume de nível superior (ID 5) e, em vez disso, montar diretamente o subvolume @data
.
root # cd /mnt root # umount /mnt/btrfs-top-level root # mkdir /data root # mount /dev/sdxy /data
Subvolumes Aninhados
Subvolumes aninhados não farão parte de instantâneos criados a partir de seu subvolume pai. Portanto, um motivo típico é excluir certas partes do sistema de arquivos de serem instantâneos.
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.