É issosegurousar fallocate --dig-holesem um arquivo enquanto ele está sendo modificado/escrito? Por exemplo, em uma imagem QCOW2 aberta por um convidado KVM?
Responder1
Eu geralmente diria não. Se o arquivo for uma imagem montada em uma VM, você poderá tentar o TRIM (por exemplo, fstrim -a). A rigor, isso não é equivalente (o TRIM também pode liberar espaço de algum arquivo excluído que não foi zerado), mas pode ser isso que você deseja.
Pode ser seguro em alguns casos específicos, mas eu não confiaria nisso. Por exemplo, quando alguns dados são transmitidos sequencialmente para um arquivosem qualquer pré-alocação, parece potencialmente seguro. Mas como isso não está implícito na documentação e dependeria apenas da implementação, eu não recomendo fortemente.
O que pode dar errado? Imagine que o aplicativo/VM irá sobrescrever algum bloco zerado e você executar simultaneamente fallocate -d. A corrida pode ser assim:
- Fallocate vê um bloco de zeros, então decide cavar um buraco ali.
- Outro aplicativo/VM grava alguns dados no bloco zerado.
- Fallocate cava um buraco no bloco.
Pode parecer que há um pequeno intervalo de tempo entre 1 e 3. Talvez seja verdade, mas fallocate pode querer liberar vários blocos subsequentes de uma vez. (Não tenho certeza, não verifiquei a implementação, mas mesmo que o oposto seja verdadeiro, você não pode confiar nisso no futuro.) Isso pode aumentar o atraso entre 1 e 3, tornando a condição de corrida muito mais provável.