![Безопасно ли использовать fallocate --dig-holes во время модификации?](https://rvso.com/image/697400/%D0%91%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%20%D0%BB%D0%B8%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20fallocate%20--dig-holes%20%D0%B2%D0%BE%20%D0%B2%D1%80%D0%B5%D0%BC%D1%8F%20%D0%BC%D0%BE%D0%B4%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8%3F.png)
Этобезопасныйиспользовать fallocate --dig-holes
для файла во время его изменения/записи? Например, для образа QCOW2, открытого гостем KVM?
решение1
Я бы сказал, что нет. Если файл — это образ, смонтированный на виртуальной машине, вы можете попробовать TRIM (например, fstrim -a). Строго говоря, это не эквивалент (TRIM также может освободить место некоторого удаленного файла, который не обнулен), но это может быть то, что вам нужно.
Это может быть безопасно в некоторых конкретных случаях, но я бы не стал на это полагаться. Например, когда некоторые данные последовательно передаются в файлбез какого-либо предварительного распределения, это звучит потенциально безопасно. Но поскольку это не подразумевается документацией и будет зависеть только от реализации, я настоятельно не рекомендую это.
Что может пойти не так? Представьте, что приложение/виртуальная машина собирается перезаписать какой-то обнуленный блок, а вы одновременно запускаете fallocate -d. Гонка может выглядеть так:
- Fallocate видит блок нулей и решает вырыть там яму.
- Другое приложение/виртуальная машина записывает в обнуленный блок некоторые данные.
- Фаллокейт выкапывает яму в блоке.
Может показаться, что между 1 и 3 есть небольшой временной интервал. Возможно, это правда, но fallocate может захотеть освободить несколько последующих блоков одновременно. (Не уверен, я не проверял реализацию, но даже если обратное верно, вы не можете полагаться на это в будущем.) Это может увеличить задержку между 1 и 3, делая состояние гонки гораздо более вероятным.