Por que o fstrim parece não aparar blocos de dados em btrfs (+ ecrypts)?

Question

Eu tenho um disco SSD com várias partições. Um deles tem um volume btrfs, montado como /home , que contém um diretório inicial do ecryptfs.

Quando eu apare os volumes, parece que o fstrim não apara blocos de dados em tal volume - por quê? Abaixo você pode ver todas as informações sobre a configuração e o procedimento que eu sigo, com comentários.

$ cat /etc/fstab :

UUID=xxx /               ext4    errors=remount-ro 0       1
UUID=yyy /media/vfio     ext4    defaults          0       2
UUID=zzz /home           btrfs   defaults          0       2

$ mount | grep sda :

/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sda1 on /media/vfio type ext4 (rw,relatime,stripe=32721,data=ordered)
/dev/sda2 on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)

$ ls -la /home /home/myuser/.Private # summary :

/home:
.ecryptfs
myuser

/home/myuser/.Private -> /home/.ecryptfs/myuser/.Private

$ df -h :

Filesystem              Size  Used Avail Use% Mounted on
/dev/sda5                16G   11G  4,7G  69% /
/dev/sda1                93G   52G   36G  60% /media/vfio
/dev/sda2               828G  542G  286G  66% /home
/home/myuser/.Private   828G  542G  286G  66% /home/myuser

Eu executo o fstrim em todos os volumes, pela primeira vez.

$ fstrim -va :

/home/myuser: 286,4 GiB (307518836736 bytes) trimmed
/home: 286,4 GiB (307485450240 bytes) trimmed
/media/vfio: 40,4 GiB (43318886400 bytes) trimmed
/: 5,4 GiB (5822803968 bytes) trimmed

Parece que o fstrim é executado duas vezes na árvore /home , devido à montagem adicional do ecryptfs. Isso seria ok (eu poderia evitá-lo executando um fstrim com pontos de montagem específicos). O problema é que o corte /home não está funcionando como esperado, pois cada execução localiza e apara a mesma quantidade de dados.

Isso é mostrado por mais uma execução.

$ fstrim -v / (tudo bem):

/: 0 B (0 bytes) trimmed

$ fstrim -v /home (isto não está bem):

/home: 286,4 GiB (307478061056 bytes) trimmed

Note que o corte sda2 ( /home ) leva algum tempo para ser executado, por isso está realmente fazendo algo.

    

Answer 1

É um mal-entendido comum se preocupar com os tamanhos relatados pelo fstrim.

Realmente não significa nada. Apenas ignore.

fstrim apenas emite o ioctl apropriado, todo o resto é a decisão do sistema de arquivos e os sistemas de arquivos se comportam de maneira muito diferente. Por exemplo, ext4 tenta evitar aparar as mesmas coisas repetidamente, assim você verá 0 bytes trimmed . xfs não se importa e reduz tudo o que é gratuito, assim você sempre verá <roughly free space> bytes trimmed . Outros sistemas de arquivos podem fazer outras coisas, tudo depende de como o sistema de arquivos escolheu implementar a lógica FITRIM syscall, se ela for implementada.

Contanto que a quantidade de dados aparados não seja maior do que o espaço livre, você deve estar bem, independentemente de qual fstrim (o sistema de arquivos realmente) reporta.

No final, apenas o SSD realmente sabe o que é atualmente aparado e o que não é. Cortar blocos já aparados não causa nenhum dano.

Não tire conclusões com base em x bytes trimmed , conforme relatado por fstrim .

Se você quiser verificar se os dados foram aparados, será necessário verificar os dados brutos no disco. ( link ) mas esse método pode não funcionar para o btrfs, nunca tentei.