Is it safe to use fallocate --dig-holes on a file while it is being modified/written? For example on a QCOW2 image opened by a KVM guest?
Asked
Active
Viewed 602 times
1
Isabell Cowan
- 123
- 1
- 8
-
3That depends on how much data loss you consider "safe"... – Michael Hampton Jan 22 '17 at 09:29
-
The hope would be none. So I take it the answer is no. Is that any different on Btrfs because it's transnational? – Isabell Cowan Jan 22 '17 at 16:13
-
It's not safe to do _anything_ to a disk image outside the VM while the VM is using it. The filesystem is irrelevant. – Michael Hampton Jan 22 '17 at 17:02
-
That's an answer I'd accept and upvote if you post it. – Isabell Cowan Jan 22 '17 at 17:40
1 Answers
4
I'd generally say no. If the file is an image mounted to a VM, you can try TRIM (e.g., fstrim -a) instead. Strictly speaking, this is not an equivalent (TRIM can also free space of some deleted file that is not zeroed), but this might be what you want.
It might be safe in some specific cases, but I wouldn't rely on it. For example, when some data are sequentially streamed to a file without any preallocation, it sounds potentially safe. But since this is not implied by documentation and it would rely only on implementation, I strongly don't recommend it.
What can go wrong? Imagine the app/VM is going to overwrite some zeroed block and you concurrently run fallocate -d. The race can look like:
- Fallocate sees a block of zeroes, so it decides to dig a hole there.
- Another application/VM writes to the zeroed block some data.
- Fallocate digs a hole in the block.
It might sound like there is a small timeframe between 1 and 3. Maybe it is true, but fallocate might want to free multiple subsequent blocks at once. (Not sure, I haven't checked the implementation, but even if the opposite is true, you cannot rely on it in the future.) This can increase the delay between 1 and 3, making the race condition much more likely.
v6ak
- 226
- 1
- 5