![¿Es seguro utilizar falocate --dig-holes mientras se modifica?](https://rvso.com/image/697400/%C2%BFEs%20seguro%20utilizar%20falocate%20--dig-holes%20mientras%20se%20modifica%3F.png)
Lo esseguro¿Usar fallocate --dig-holes
en un archivo mientras se modifica/escribe? ¿Por ejemplo, en una imagen QCOW2 abierta por un invitado KVM?
Respuesta1
Generalmente diría que no. Si el archivo es una imagen montada en una máquina virtual, puede probar TRIM (por ejemplo, fstrim -a) en su lugar. Estrictamente hablando, esto no es un equivalente (TRIM también puede liberar espacio de algún archivo eliminado que no esté puesto a cero), pero esto podría ser lo que desea.
Puede que sea seguro en algunos casos específicos, pero no confiaría en ello. Por ejemplo, cuando algunos datos se transmiten secuencialmente a un archivosin ninguna preasignación, suena potencialmente seguro. Pero como esto no está implícito en la documentación y dependería únicamente de la implementación, no lo recomiendo enfáticamente.
¿Qué puede ir mal? Imagine que la aplicación/VM va a sobrescribir algún bloque puesto a cero y usted ejecuta simultáneamente fallocate -d. La carrera puede verse así:
- Fallocate ve un bloque de ceros, por lo que decide cavar un hoyo allí.
- Otra aplicación/VM escribe algunos datos en el bloque puesto a cero.
- Fallocate cava un agujero en el bloque.
Puede parecer que hay un pequeño período de tiempo entre 1 y 3. Tal vez sea cierto, pero es posible que Fallcate desee liberar varios bloques posteriores a la vez. (No estoy seguro, no he verificado la implementación, pero incluso si ocurre lo contrario, no puedes confiar en ello en el futuro). Esto puede aumentar el retraso entre 1 y 3, haciendo que la condición de carrera sea mucho más probable.