I would like to use BTRFS to host VMs in VirtualBox to be able to use Snapshots without LVM or such. In theory I don't need CoW
behaviour all the time because of performance reasons and using nodatacow
it seems I don't need to. What I would like to have instead is an approach from my understanding Windows and NTFS seems to be using: Data is changed all the time without CoW
, but if one creates a file system snapshot the current data is kept save within that snapshot by copying data away if it is to be changed in any way. The important thing seems to be that this only happens exactly one time per snapshot and really only for the modified blocks. So after a block to be modified has been copied away at first, all subsequent modifications to the same block are just applied, again without CoW
behaviour.
Besides copying the original block of changed data to some safe place, from a performance perspective this makes a lot of sense to me and I would like to have exactly that behaviour to host my VMs. Those write some data all the time and I simply don't see how I need CoW
behaviour for all those changes.
I only want CoW
after I created a file system snapshot by purpose, e.g. for backup purposes. Afterwards I need CoW
of course to be able to keep my snapshots consistent as long as I need it. But again, even after creation of the snapshots I wouldn't need CoW
for all eternity for all data, but only once for the afterwards changed blocks. All changes after the first one could simply be applied as without any CoW
.
From my understanding of the BTRFS docs, if CoW
happens once to some file, it keeps happening forever. But I might be wrong of course...
So, is what I would like to have possible at all with BTRFS?
Answer
If
CoW
happens once to some file, it keeps happening forever. But I might be wrong of course.
I think you are wrong. I have found this question about taking snapshots of a BTRFS volume mounted with nodatacow
. There is a citation there (from the BTRFS mailing list) that seems crucial to your case:
On a NOCOW file the first write to a fileblock (4096 bytes) after a snapshot must still be COW, because the snapshot locks the old version in place, and now the fileblock has changed, so it MUST be written elsewhere despite the NOCOW in ordered to keep the snapshot as it was. However, the file does retain the NOCOW attribute and additional writes to the same fileblock will be in-place... until the next snapshot of course.
It looks like nodatacow
mount option gives you exactly what you want. Just remember there are limitations:
nodatacow
Do not copy-on-write data for newly created files, existing files are unaffected. This also turns off checksumming! […] potentially getting partially updated files on system failures. […] switches off compression!
Source: BTRFS mount options.
Comments
Post a Comment