Aviso: este artigo se aplica a todos os sistemas de arquivos CoW no Linux que suportam reflink durante a cópia. No momento, eles são: BTRFS, XFS e OCFS2.
Evite holivar sobre qual FS é melhor: Btrfs, XFS, Reiser4, NILFS2, ZFS ou outros não mencionados.Antecedentes
- 21 de julho de 2001 - A Namesys publica o anúncio do Reiser4 . A DARPA patrocina o desenvolvimento.
- 20 de novembro de 2003 - A Namesys publica alguns benchmarks do Reiser4 .
- 24 de agosto de 2004 - A Namesys faz um lançamento público do Reiser4 .
- 14 de setembro de 2004 - anúncio do ZFS.
- 16 de novembro de 2005 - O ZFS está incluído no OpenSolaris build 27.
- Setembro de 2006 - Hans Reiser preso por matar a esposa, Nina Reiser. Início do fim da Namesys
- 12 de junho de 2007 - Anúncio da Btrfs por Chris Mason (ex-funcionário da Namesys).
- 22 de setembro de 2011 - Um ticket com uma solicitação para implementação de reflink apareceu no ZFSonLinux.
- 2012 - Btrfs reconhecido como Oracle Linux e SUSE Linux Enterprise estáveis
- 21 de janeiro de 2013 - o rótulo do experimento foi removido com Btrfs no código-fonte do kernel do Linux.
- Maio de 2019 - Btrfs removido do RHEL 8 (razões políticas ocultas são suspeitas de Btrfs promovidos pela Oracle)
Expectativas de cópia em sistemas de arquivos CoW
Quando o Reiser4 foi anunciado em 2001, fiquei inspirado e apaixonado pelos recursos de Copy-on-Write. Basta pensar, podemos facilmente e simplesmente ter quantas cópias de projetos diferentes você quiser, e fisicamente o disco armazenará apenas diferenças entre eles!
Além disso, a velocidade da cópia deve aumentar indecentemente. Devido ao fato de que, ao copiar, apenas um link de refluxo para o arquivo antigo seria criado. Ao gravar em um novo arquivo, os setores para dados alterados seriam alocados automaticamente. Como resultado, teríamos os mesmos setores para as partes comuns dos arquivos e partes diferentes seriam registradas em setores diferentes.
Parecia uma panacéia para criar contas para hospedagem compartilhada e agora é a melhor solução para máquinas virtuais e contêineres leves. Afinal, não podemos desperdiçar espaço em arquivos idênticos, ao mesmo tempo que permite aos usuários alterá-los facilmente.
No entanto, Hans Riser subiu ao telhado e matou sua esposa, e sua ideia (provavelmente por razões políticas) não foi incluída no núcleo. Talvez, afinal, a história dependa de uma pessoa específica?
O ZFS foi publicado sob uma licença incompatível com o Linux e, portanto, não foi incluído no kernel. Portanto, a introdução do ZFS no Linux ficou lenta por muito tempo.
Depois disso, comecei a esperar pelo Btrfs. E apenas 6 anos após o anúncio, foi reconhecido pelos desenvolvedores do kernel Linux como estável.
Depois disso, não tive pressa de usar os sistemas Cow, pois o próprio paradigma Copy-on-Write implica em fragmentação aumentada, porque as alterações de dados são gravadas em um novo local todas as vezes.
Para o HDD, a fragmentação diminui o desempenho, pois o processo de reposicionar o bloco de cabeças de leitura é uma operação muito demorada.
Portanto, adiei pessoalmente a implementação de btrfs em minhas máquinas até que elas mudassem para SSD.
Observo que os SSDs também não gostam de fragmentação, todos sabem que, para um SSD, a gravação / leitura linear pode ser dezenas de vezes mais rápida que o acesso aleatório.
Mas o desempenho de um SSD fragmentado não é tão dramático quanto o de um HDD.
Então, e a velocidade de cópia com o CoW?
E finalmente chegou a hora. Quando os SSDs se tornaram confiáveis o suficiente, comecei a usar sistemas de arquivos CoW com poder e principal. Mais especificamente, Btrfs e Nilfs2.
Dominando as emocionantes possibilidades dos snapshots, esqueci por um tempo minhas expectativas dos anos 2000 sobre a cópia ultra-rápida de arquivos.
Depois de algum tempo, decidi realizar testes. E, para minha grande decepção, não vi nenhum aumento de velocidade da CoW ao copiar. Aqui está o resultado em um SSD SATA:
time cp -a /usr /usr1 real 0m15,572s user 0m0,240s sys 0m4,739s
Descobriu-se que, para usar o CoW, é necessário especificar uma chave especial.
time cp -a --reflink=auto /usr /usr2 real 0m3,166s user 0m0,178s sys 0m2,891s
Somente neste caso, vemos uma vantagem de 5 vezes. A propósito, o tamanho da vantagem aumenta indefinidamente com o aumento do tamanho do arquivo. A pasta
/usr que eu copiei é principalmente arquivos pequenos.
Fiquei incrivelmente surpreso por que a principal vantagem do sistema de arquivos CoW não é usada por padrão. De fato, para isso ela foi criada!
Nesse caso, testei a cópia na seção Btrfs. Mas você obterá um resultado semelhante com qualquer outro sistema de arquivos CoW que suporte reflink.
Qual é o problema, Billy?
O problema está no cp. Por padrão, ele não usa o CoW ao copiar. Embora possa.
Você pode dizer - eu não uso cp. No entanto, sob o capô do Linux, ele é usado em quase todos os lugares. Muitos programas, quando precisam copiar algo, usam cp e não suas "bicicletas".
Por que os desenvolvedores do coreutils tomaram uma decisão tão ambígua, que atravessou metade das vantagens dos sistemas de arquivos CoW?
Acontece que Pádraig Brady, responsável pelo desenvolvimento dos coreutils GNU, decidiu.
Aqui está sua lógica :
- Por padrão, o cp não usa o CoW, pois alguém pode usar a cópia para aumentar a probabilidade de salvar o arquivo em disco após a destruição do sistema de arquivos.
- Em termos de desempenho, se houver algum tipo de processo sensível a atraso, convém que o registro principal seja feito durante a cópia; portanto, se isso acontecer mais tarde, poderá haver um atraso ao reposicionar as cabeças do disco rígido. Observe que a partir da versão 8.24 coreutils, mv usa a opção reflink por padrão.
Pádraig Brady responde o texto em inglêsNão é o padrão, pois, por motivos de robustez, é possível que ocorra uma cópia para proteger contra corrupção de dados. Também por razões de desempenho, convém que as gravações ocorram no momento da cópia, em vez de algum processo sensível à latência, trabalhando em um arquivo CoW e sendo atrasado pelas gravações, possivelmente em uma parte diferente de um disco mecânico. Observe que a partir do coreutils v8.24 mv irá refletir por padrão, pois não possui as restrições acima.
Em termos de velocidade para mv, praticamente não há benefício do CoW ao mover arquivos. Dentro de um único sistema de arquivos, o mv quase sempre funciona muito rápido.
Novamente, surge a questão da influência da personalidade na história. Ao inserir várias letras no código-fonte do programa de maneira diferente, é possível diminuir a velocidade da cópia para dezenas / centenas de milhões de usuários (aqui você precisa considerar que agora a maioria das pessoas usa serviços em nuvem de uma forma ou de outra, mesmo que não possuam computador), reduza a eficiência do uso de unidades e aumentar suas vendas em todo o mundo.
Análise de argumento de Pádraig
O primeiro argumento faz algum sentido. Usuários inexperientes podem realmente fazer backup de arquivos valiosos no mesmo sistema de arquivos.
Segundo argumento. Se você ler mais comentários sobre os atrasos de Pádraig, descobrirá que ele tinha em mente situações de banco de dados em que, ao gravar em um arquivo existente, pode haver um atraso devido ao sistema de arquivos procurar espaço livre. Mas no caso do sistema de arquivos CoW, novos setores sempre serão pesquisados para gravação devido à natureza do CoW, como observou Jan Kanis. Portanto, na minha opinião, o segundo argumento é insustentável.
No entanto, em sistemas CoW, é realmente possível obter um atraso ou até o erro "Sem espaço" ao gravar no arquivo do banco de dados. Para evitar isso, você precisa criar inicialmente um diretório vazio com o CoW desativado para o banco de dados.
Desative o CoW no diretório / arquivo da seguinte maneira:
chattr +C /dir/file chattr +C /dir/dir
Há também a opção de montar nodatacow. Será aplicado a todos os arquivos criados recentemente.
Mas e se quisermos usar o CoW ao copiar por padrão?
- A maneira radical é consertar os coreutils. Talvez crie seu pacote em seu repositório privado.
Arquivo cp.c do patch :
-x->reflink_mode = REFLINK_NEVER; +x->reflink_mode = REFLINK_AUTO;
- Uma solução menos radical é escrever um alias de cp para seu shell. Para o bash, por exemplo:
Na pasta /etc/profile.d , crie um cp_reflink.sh cp_reflink.sh com o conteúdo:
Esta solução funcionará em quase todos os casos quando o cp for acessado de um shell pelo nome. Mas se / bin / cp for usado nos scripts, o alias não funcionará e a cópia ocorrerá normalmente.
Gerenciadores de arquivos e reflink
Status em 31 de outubro de 2019:
- Midnight Commander - suporta.
- Krusader - não suporta.
- Dolphin - não suporta.
- Nautilus - não suporta.
- Nemo - Suportes.
Linguagens de programação, chamadas de sistema e reflink
A maioria das linguagens de programação não possui suporte a refluxo.
Em C, muitos programadores ainda copiam
usando loops e buffers .
A chamada do sistema
sendfile não usa reflink.
cp usa a
chamada do sistema
ioctl com o sinalizador FICLONE.
Eu acho que se você precisar copiar algo no código, é aconselhável fazê-lo como o
cp faz ou apenas chamar
cp --reflink=auto .
Conclusões
Com o advento da era da virtualização onipresente e do SSD, tornou-se muito importante o uso de sistemas de arquivos CoW. Eles são convenientes para criar instantâneos, cópias rápidas. De fato, ao usar o CoW ao copiar, fazemos
automaticamente a deduplicação de dados .
Atualmente, apenas três sistemas de arquivos suportam esse tipo de cópia: BTRFS, XFS e OCFS2.
Espero sinceramente que o suporte ao reflink seja concluído no ZFS e NILFS2, pois eles já oferecem suporte ao CoW por mecanismos internos.
No entanto, em todas as distribuições Linux, o CoW é desativado ao copiar arquivos, e precisamos especificar explicitamente as chaves correspondentes ou usar vários truques, como aliases ou patches.
18 anos se passaram desde o anúncio do Reiser4, no entanto, até agora, a cópia leve de COW não entrou em nossa vida em nenhum lugar.
PS Docker e CoW
Você sabia que o Docker suporta btrfs para armazenamento? Esta opção deve estar ativada. Não está selecionado por padrão.
O sistema de arquivos CoW em teoria é o complemento perfeito para fácil virtualização quando diferentes máquinas virtuais usam o mesmo kernel.
Na minha opinião, é muito mais orgânico que o OverlayFS e o Aufs, que são muletas tecnológicas para simular o CoW.
Para usar o Btrfs no Docker, é necessário:
- Em uma instalação nova (sem imagens e máquinas virtuais) do Docker, monte um volume Btrfs separado em
/var/lib/docker - Adicionar opções ao arquivo de configuração de inicialização do Docker
Para o Gentoo e o Calculate Linux, este é
/etc/conf.d/docker DOCKER_OPTS="--storage-driver btrfs --data-root /var/lib/docker"
E aqui está a
instrução completa para todas as distribuições.
Adições de comentários
XFS e CoW
constb (
fonte ): No XFS, o CoW também nem sempre é suportado. Você precisa criar um sistema de arquivos com
mkfs.xfs -m reflink=1 .
Já no FS criado, você não pode "ativar" o suporte ao CoW. além disso, em kernels até 4.11, a inclusão dessa opção causa avisos vermelhos no dmesg, indicando que o recurso é experimental.
MacOS e CoW
MMik (
origem ): no OS X, uma opção semelhante ao comando
cp é
-c .
Envolve o uso da chamada de sistema atômico
clonefile() , que cria uma entrada no sistema de arquivos sobre um novo arquivo no qual as referências aos blocos de dados são idênticas às originais. Os atributos e atributos estendidos do arquivo são copiados, entradas da lista de controle de acesso (ACL), com exceção das informações do proprietário do arquivo e com a redefinição dos bits setuid / setgid. Funciona no mesmo sistema de arquivos, requer suporte do sistema de arquivos (atributo ATTR_VOL_CAPABILITIES, sinalizador VOL_CAP_INT_CLONE).
Suportado desde o OS X 10.12 (Sierra) e apenas no sistema de arquivos
APFS .
Agradecimentos:
PPS Dirija os erros notados em um pessoal. Eu aumento o carma por isso.
Você pode experimentar sistemas de arquivos CoW solicitando uma máquina virtual do
RUVDS com o cupom abaixo.
