Algum sistema de arquivos implementa o mecanismo Copy on Write para CP


16

Vimos o SO executando a otimização de cópia na gravação ao criar um processo. O motivo é que na maioria das vezes a bifurcação é realizada pelo exec, portanto, não queremos incorrer no custo das alocações de páginas e copiar os dados do espaço de endereço do chamador desnecessariamente.

O mesmo acontece com o CP no Linux com sistemas de arquivos ext4 ou xfs (journaling). Se isso não acontecer, por que não?


Espero que alguém vai responder a esta pergunta interessante
Karim Manaouil

No entanto, acho que não, porque, por exemplo, armazenar um arquivo grande levaria um tempo consideravelmente maior (copiar dados para novos blocos). Se houvesse uma COW em tais sistemas de arquivos (ext3 / ext4 pelo menos), você não notaria a latência de tempo (talvez nesse caso apenas replicando o inode sem ponteiros para blocos de dados e marcando algum sinalizador de vaca).
Karim Manaouil

O Copy-on-Write é implementado no ZFS e, de fato, possui clones de sistema de arquivos / volume muito baratos. ext4 / xfs tem muito primitiva formato em disco, creio eu, para apoiar essa
myaut

Respostas:


7

A palavra-chave para pesquisar é reflink. Foi recentemente implementado no XFS.

EDIT: a implementação do XFS foi inicialmente marcada como EXPERIMENTAL. Este aviso foi removido na versão 4.16 do kernel, vários meses depois que eu escrevi o acima :-).


11

Na cp página do manual :

Quando --reflink [= sempre] for especificado, execute uma cópia leve, na qual os blocos de dados são copiados apenas quando modificados. Se isso não for possível, a cópia falhar ou se --reflink = auto for especificado, volte para uma cópia padrão.

Isso funciona em sistemas de arquivos que suportam Copy-on-Write ( reflink ), principalmente BTRFS no momento. A implementação do reflink XFS está em desenvolvimento [1] [2] .


1
Alguns sistemas de arquivos de rede como NFS, CIFS, OCFS2 também podem repassá-los ao servidor.
Stéphane Chazelas

2

O Linux possui uma chamada de sistema que permite que os processos do espaço do usuário digam ao kernel para fazer cópias nas cópias de arquivos gravadas. FICLONERANGE e FICLONE usados ​​como opções para ioctl permitem copiar cópias de arquivos e intervalos nos arquivos a serem feitos.

Isso é usado pelo cp --reflink para fazer as cópias nas quais o sistema de arquivos suporta isso.


1

A menos que você introduza um syscall para cp(ou pelo menos copie um bloco), o sistema operacional dificilmente descobrirá que os dados que o cpprograma irá gravar são os mesmos que foram lidos em outro bloco. Além disso, você teria uma sobrecarga adicional para gerenciar o cenário "vários arquivos compartilham os mesmos blocos". Arquivos grandes e similares que diferem apenas em alguns blocos ocorrem raramente. Portanto, no geral, é mais barato copiar esses blocos e adicionar essa sobrecarga administrativa a todos os arquivos.

Agora, se você "copiar" arquivos (muitos deles) adicionando outro clone / instantâneo do sistema de arquivos no, digamos, BTRFS, a situação é diferente: Agora você "copiou" todos os arquivos no sistema de arquivos e quaisquer alterações em eles serão copiados na gravação. Isso existe, mas não no ext4.

"Journalling" é um conceito completamente independente disso, são as estruturas administrativas dos arquivos que contam.


Arquivos grandes, sendo uma cópia binária dos outros tempos extremamente raros, diferem em um único bit e quando isso ocorre devido a um erro.
bitifet

Uma chamada do sistema para cópia foi introduzida (veja minha resposta).
Q o ornitorrinco
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.