1

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 CoWfor 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?

6
  • Did you actually experience performance problems with CoW or are you concerned about theoretical issues?
    – Daniel B
    Commented Mar 15, 2017 at 11:32
  • @DanielB I'm just concerned and thinking about things, because one can read very different statements regarding CoW and use cases with VMs or databases. Commented Mar 15, 2017 at 11:34
  • Are you talking about FS or VM snapshots?
    – Seth
    Commented Mar 15, 2017 at 11:35
  • @Seth file system level snapshots. Commented Mar 15, 2017 at 11:37
  • 1
    Just FYI, this isn't really a function of NTFS. Volume shadow copy is layered above the volume driver and below the file system driver. As such it is file system agnostic. It doesn't care about file system metadata, file contents, or any of that. It's all done in terms of logical blocks (blocks within a volume). Commented Mar 15, 2017 at 12:04

1 Answer 1

1

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.

1
  • Great source, thanks! The limitations might be no problem at all, by using e.g. ext4 or NTFS I already have the same and can potentially live with those. In the end, it's simply good to be able to choose. :-) Commented Mar 23, 2017 at 7:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .