<div dir="ltr"><div>Not to heat up an argument or anything, but as coincidence would have it, this article was in my news feed this morning and I thought it might be relevant.  I don't know if the writer used credible testing methods or anything, nor do I endorse his opinion in anyway, etc...</div><div><br></div><div><a href="https://www.ctrl.blog/entry/btrfs-vs-ext4-performance.html">https://www.ctrl.blog/entry/btrfs-vs-ext4-performance.html</a></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 24 May 2019 at 00:21, Chris Irwin <<a href="mailto:chris@chrisirwin.ca">chris@chrisirwin.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, May 23, 2019 at 10:06:32PM -0400, Remi Gauvin wrote:<br>
> many places, including the official<br>
>BTRFS wiki, recommend disabling Copy-On-Write for database or VM Image<br>
>files.<br>
<br>
I use BTRFS for my desktop and laptop (both home and work) and have no <br>
issues or complaints. Automatic snapshots have saved me several times.<br>
<br>
However, BTRFS is a tool. You can use it for the features it was <br>
intended for (COW and checksumms), or you can use it wrong. Anything <br>
suggesting disabling COW on BTRFS is simply plain wrong, regardless of <br>
whether it is some blog or official documentation.<br>
<br>
Disabling COW for VMs on BTRFS means:<br>
<br>
    * You're not getting data checksums (they require COW)<br>
    * You're not using snapshots (they silently enable COW)<br>
<br>
If you're not using either of those: Why are you bothering with BTRFS?<br>
<br>
BTRFS with COW disabled is worse than ext4: You're not getting any <br>
actual feature benefits, and you've lost the more plentiful and robust <br>
ext4 recovery tools (should you ever need them).<br>
<br>
Additionally some features (like snapshots) will silently enable COW,<br>
even on files that COW was "disabled", and defragmenting (including <br>
autodefrag) will cause data duplication between snapshots (which were <br>
deduped by virtue of COW).<br>
<br>
For Virtual Machines and Databases, I'd really just recommend having an <br>
ext4 LV for those. I keep VMs and databases on ext4 (at home) or xfs (at <br>
work, due to RHEL).<br>
<br>
(I prefer ext4 use for home, because you can't shrink xfs)<br>
<br>
>However, the BTRFS raid implementation is completely dependent<br>
>on CoW to maintain synchronization between mirrors. Any event that<br>
>interrupts writes to a mirrored file with CoW disabled will result in<br>
>discrepancies between the mirrored copies, and they are never<br>
>automatically fixed.. not even if you run a scrub.<br>
<br>
Which makes sense. Disabling COW disables data checksums, and scrub <br>
searches for checksum errors.<br>
<br>
-- <br>
Chris Irwin<br>
<br>
email:   <a href="mailto:chris@chrisirwin.ca" target="_blank">chris@chrisirwin.ca</a><br>
 xmpp:   <a href="mailto:chris@chrisirwin.ca" target="_blank">chris@chrisirwin.ca</a><br>
  web: <a href="https://chrisirwin.ca" rel="noreferrer" target="_blank">https://chrisirwin.ca</a><br>
<br>
_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a><br>
<a href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" rel="noreferrer" target="_blank">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote></div>