In the "Gotchas" section of the BTRFS wiki it's mentioned that performance issues could occur with highly fragmented files (vm images and databases). The solution for this is to disable copy-on-write for those files.

For a Debian installation, in what system directories should we also disable copy-on-write (mounting them in a nodatacow subvolume)?

To reduce the broadness of the question, assume it's a server with full allocation image VMs (log server, file server, for example). Also, operations like btrfs add/remove missing causes a lot of logging to occur in the host machine.

My question is, besides disabling copy-on-write for those "write active" VMs, is disabling it on the /var/log directory enough or are there other system directories/files that I could also do this from the start (like all of /var and /tmp as Stephen Harris suggested)? Or is it just a matter of starting somewhere, checking regularly for fragmented files and performance issues, and disabling the copy-on-write when needed?

  • 1
    /tmp and /var are obvious ones, but the situation will be very dependent on your workloads. A VM server may not want the VM storage devices handled that way. I'm going to flag this 'too broad' because it's very case specific. – Stephen Harris Aug 25 '16 at 1:40
  • But for the directories that you mentioned are there any cases where nodatacow would be prejudicial in any way? – xpto Aug 25 '16 at 2:06
  • 1
    It depends on the workload. You just have to think through whether copy-on-write is going to generate a lot of I/O. For example, with VM's it's better to just allocate everything up front rather than each and every time something on the guest OS decides to change something. Writing it out all at once sequentially takes less time cumulatively and it doesn't put any of the latency into the operations that reflect the ultimately useful parts of using a VM. – Bratchley Aug 25 '16 at 3:27
  • 1
    It might be a good idea to profile your I/O use for whatever you're planning and if it contains a lot of random small writes then CoW is probably going to be detrimental. – Bratchley Aug 25 '16 at 3:30

Btrfs isn't supposed to be run in that mode, even if it's supported: for e. g., it'd have turned Off checksumming and thus you'd have something very similar to EXT4, XFS and other typical FSes.

Thoughts about /var/log also don't have any reasonable background because log files typically aren't overwritten but rather appended mostly.

As I've pointed out most of your concerns were already addressed on this very site.

Not the answer you're looking for? Browse other questions tagged or ask your own question.