I am looking at implementing btrfs in raid 10 configuration for a database server and I am an confused about the nodatacow option.
According to https://btrfs.wiki.kernel.org/index.php/Gotchas:
Files with a lot of random writes can become heavily fragmented
(10000+ extents) causing trashing on HDDs and excessive multi-second
spikes of CPU load on systems with an SSD or large amount a RAM. On
servers and workstations this affects databases and virtual machine
images. The nodatacow mount option may be of use here, with associated
gotchas.
The documentation then states that nodatacow option is:
Do not copy-on-write data for newly created files, existing files are
unaffected. This also turns off checksumming! IOW, nodatacow implies
nodatasum. datacow is used to ensure the user either has access to the
old version of a file, or to the newer version of the file. datacow
makes sure we never have partially updated files written to disk.
nodatacow gives slight performance boost by directly overwriting data
(like ext[234]), at the expense of potentially getting partially
updated files on system failures. Performance gain is usually < 5%
unless the workload is random writes to large database files, where
the difference can become very large. NOTE: switches off compression !
Does this mean that this option should be selected for disks in database servers AND this using this option will disable corruption checksums?
Best Answer
Yes, it's generally a good idea for databases, and yes it does disable checksumming (for the same reason that it disables in-line compression, and will probably disable encryption too once that's implemented).
That said, it's generally a better idea to not mount the whole filesystem with it, and instead mark the directory in which the database files will be stored before they are created by running
chattr +Con it. That particular attribute has the same effect as thenodatacowmount option, but operates on a per-file basis, and is inherited from the directory a file is created in.