Por que mover arquivos entre subvolumes btrfs é uma operação cara?

Pelo que entendi, os subvolumes btrfs compartilham o mesmo sistema de arquivos "storage", então fiquei surpreso em saber que mover arquivos entre subvolumes diferentes é uma operação cara, como se mover entre sistemas de arquivos diferentes (copy + delete).

Fiquei especialmente surpreso quando alguém sugeriu esta solução alternativa: copiar arquivos entre subvolumes e depois excluir os originais. Diz-se que esta é uma operação barata (movendo-se apenas em metadados). Como é que subvolumes diferentes podem compartilhar blocos de dados ao usar COW, mas não na operação mais fácil de mover dados?

file-transfer benchmarking btrfs

— m.alessandrini
fonte

Isso não responde à sua pergunta, mas você pode estar interessado em saber que a partir do coreutils 8.24 (lançado em 3 de julho de 2015), mvtentará um reflink antes de retornar a uma cópia padrão ( changelog ).

— Vincent Yu

@VincentYu obrigado pela informação. Mas uma operação de mover / renomear não deve ser gerenciada pelo próprio sistema de arquivos, em vez de utilitários de espaço do usuário? Pelo que eu li, esse comportamento de movimentação é o mesmo, mesmo que seja feito dentro do mesmo ponto de montagem, ou seja, não ter o subvolume montado em outro diretório para que o kernel talvez não reconheça que é o mesmo sistema de arquivos.

— m.alessandrini

@VincentYu apenas para informação, e despertado pela nova resposta, eu tentei mover um arquivo grande entre subvolumes com um sistema mais atualizado (teste debian, kernel 4.6.0, coreutils 8.25-2), mas nada mudou.

— m.alessandrini

@ m.alessandrini Acabei de descobrir que, para poder usar cp --reflinkentre dois subvolumes, fui forçado a montar o subvolume de nível superior e emitir o cpcomando dentro desse namespace , caso contrário, cpsairia com um erro dizendo...Invalid cross-device link

— Dzamo Norton

@DzamoNorton o fato é que anteriormente ele não funcionava mesmo na configuração que você descreve (todos os subdiretórios do diretório atual), onde a cópia-retrink funcionava. Mas eu apenas tentei e hoje o movimento é uma operação de tempo zero, também (kernel 4.16), então eu acho que isso foi resolvido.

— m.alessandrini

Como é que subvolumes diferentes podem compartilhar blocos de dados ao usar COW, mas não na operação mais fácil de mover dados?

mv usa o renomear syscall para tentar o movimento. A renomeação de kernel do btrfs detecta a movimentação de subvolumes cruzados e explicitamente desaprova isso (mesmo se sob o mesmo ponto de montagem):

/* we only allow rename subvolume link between subvolumes */
if (old_ino != BTRFS_FIRST_FREE_OBJECTID && root != dest)
    return -EXDEV;

Isso provavelmente tem a ver com a contabilidade de subvolume inode e os caminhos de código que essas operações executam. A cópia do reflink está realmente criando novos metadados (mas os dados em si são CoW) contabilizados no novo subvolume. Em teoria, eles provavelmente poderiam fazer a renomeação "mover" os metadados fazendo algo similar ao que a cópia --reflink seguiu a rm source ... simplesmente ninguém fez o esforço para fazê-lo.

— Will Brown
fonte

Obrigado, eu procurei o código do kernel por curiosidade, e além de não entender isso à primeira vista (obviamente), eu realmente não entendi essa frase no comentário. Você sabe o que isso pode significar?

— m.alessandrini

Os subvolumes aparecem como entradas de diretório (também conhecidas como "link de subvolume") em qualquer parte do sistema de arquivos. O comentário está dizendo que você só pode renomear (aka mover) as entradas do diretório subvolume entre subvolumes e não diretórios / arquivos reais.

— Will Brown