Remover arquivos demora muito

7

Versão curta : rm -rf mydir , com mydir (recursivamente) contendo 2,5 milhões de arquivos, leva cerca de 12 horas em uma máquina quase inativa.

Mais informações : A maioria dos arquivos excluídos é links físicos para arquivos em outros diretórios (o diretório que está sendo excluído é, na verdade, o backup mais antigo feito por rsnapshot ; o comando rm é realmente dado por rsnapshot ). Portanto, a maioria das entradas do diretório está sendo excluída - o conteúdo do arquivo em si não é muito; é da ordem de algumas dezenas de GB.

Estou longe de ter certeza de que btrfs é o culpado. Lembro-me de backup também foi muito lento antes de começar a usar btrfs , mas não tenho certeza de que a lentidão estava na exclusão.

A máquina é uma Intel Core i5 de 2,67 GHz com 4 GB de RAM. Ele tem dois discos SATA: um tem o sistema operacional e algumas outras coisas, e o disco de backup é de 1 TB WDC WD1002FAEX-00Z3A0 . A placa-mãe é uma Asus P7P55D.

Editar : A máquina é um wheezy do Debian com o Linux 3.16.3-2~bpo70+1 . É assim que o sistema de arquivos é montado:

root@thames:~# mount|grep rsnapshot
/dev/sdb1 on /var/backups/rsnapshot type btrfs (rw,relatime,compress=zlib,space_cache)

Editar : usar rsync -a --delete /some/empty/dir mydir demora cerca de 6 horas. Uma melhoria significativa sobre rm -rf , mas ainda muito eu acho. ( Explicação de por que rsync é mais rápido que rm : "[M] ost filesystems armazena suas estruturas de diretório em um btree formato, a ordem [no] que você excluir arquivos é ... importante. É necessário evitar rebalancing a btree quando você realizar o unlink .... rsync -a --delete ... faz exclusões em ordem ")

Editar : Anexei outro disco que tinha 2,2 milhões de arquivos (recursivamente) em um diretório, mas no XFS. Aqui estão alguns resultados comparativos:

                  On the XFS disk      On the BTRFS disk
Cached reads[1]       10 GB/s               10 GB/s
Buffered reads[1]     80 MB/s              115 MB/s
Walk tree[2]         11 minutes            43 minutes
rm -rf mydir[3]       7 minutes            12 hours

[1] Com hdparm -T /dev/sdX e hdparm -t /dev/sdX .
[2] Tempo gasto para executar find mydir -print|wc -l imediatamente após a inicialização.
[3] No disco XFS, isso foi logo depois de andar na árvore com find . No disco BTRFS, é a medida antiga (e não acho que foi com a árvore armazenada em cache).

Parece ser um problema com btrfs .

    
por Antonis Christofides 11.02.2015 / 21:50

3 respostas

2

Bem, isso ainda é um problema do Btrfs, é bem sabido que a exclusão de muitos arquivos pequenos demora bastante em comparação a outros sistemas de arquivos.

Se você não gostar, você pode esperar até que o upstream o conserte ou passar para outro sistema de arquivos que o faça melhor.

Seu erro principal é usar um kernel antigo (3.16, sim, já era antigo quando você postou) com o btrfs. Btrfs é um sistema de arquivos que ainda está em desenvolvimento pesado, então você deve sempre ficar com a última e melhor versão do kernel para entrar em contato com as melhorias. Se a sua distribuição não faz backports, você pode fazer isso sozinho ou está estragado.

O Btrfs obteve muitas melhorias de desempenho na versão do kernel 3.19 - esta é a versão mínima que você deve usar na produção, sua versão do kernel 3.16 claramente suga sem backports.

Lembre-se também que, de acordo com Chris Mason, ele considera a Btrfs estável por enquanto, mas ainda não está pronta para produção.

    
por 30.12.2015 / 10:16
1

Estou um pouco atrasado para essa festa, mas aqui está um truque para excluir rapidamente árvores btrfs extremamente grandes:

  1. Crie um subvolume fictício no mesmo sistema de arquivos btrfs.
  2. Mova o diretório de nível superior que você deseja remover para o dito subvolume - esta operação deve ser realmente rápida se você estiver fazendo isso no mesmo sistema de arquivos btrfs, mesmo em subvolumes.
  3. Destrua o subvolume.

O kernel vai começar a recuperar espaço em segundo plano, assim você não terá o espaço disponível imediatamente, mas o processo deve ser muito mais rápido do que fazer qualquer tipo de exclusão de usuário.

    
por 05.09.2018 / 09:11
0

Você pode renomear o diretório e excluir o diretório renomeado em um processo em segundo plano. Isso não vai acelerar a operação de exclusão. No entanto, isso permitiria que o programa continuasse com um diretório vazio enquanto a operação de exclusão estava acontecendo ao lado.

Não tenho certeza se isso funcionará no seu caso de uso. Isso depende se o programa não puder continuar até que o disco esteja ocioso (isto é, ele fará algumas operações pesadas de disco). Depende se o programa vai encher o disco com muitos dados.

    
por 11.12.2015 / 19:44

Tags