Это сейф использовать fallocate --dig-holes в файл во время его изменения / записи? Например, на образе QCOW2, открытом гостем KVM?
Я бы вообще сказал нет. Если файл представляет собой образ, подключенный к виртуальной машине, вы можете вместо этого попробовать TRIM (например, fstrim -a). Строго говоря, это не эквивалент (TRIM также может освободить место в каком-то удаленном файле, который не обнулен), но это может быть то, что вам нужно.
В некоторых конкретных случаях это может быть безопасно, но я бы не стал на это полагаться. Например, когда некоторые данные последовательно передаются в файл без предварительного распределения, это звучит потенциально безопасно. Но поскольку это не подразумевается в документации и зависит только от реализации, я настоятельно не рекомендую это делать.
Что может пойти не так? Представьте, что приложение / виртуальная машина собирается перезаписать какой-то обнуленный блок, и вы одновременно запускаете fallocate -d. Гонка может выглядеть так:
Может показаться, что между 1 и 3 небольшой таймфрейм. Возможно, это правда, но fallocate может захотеть освободить сразу несколько последующих блоков. (Не уверен, я не проверял реализацию, но даже если верно обратное, вы не можете полагаться на это в будущем.) Это может увеличить задержку между 1 и 3, что делает состояние гонки гораздо более вероятным.