<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>I'm seeing corruption occur after doing a balance of a btrfs volume. Scrubs before the balance are error free. Scrubs after balance have many errors, so far all seem to be either unlisted or point to a systemd-journal log path. Example:</div><div><br></div><div>[ 318.029771] btrfs: checksum error at logical 2209439744 on dev /dev/sda4, sector 6412464, root 256, inode 25764, offset 6746112, length 4096, links 1 (path: var/log/journal/10db2764a11a4829bf82a94c6559d121/system.journal)</div><div><br></div><div>Further, this is not a corruption of btrfs metadata, but data itself:</div><div><br></div><div>[ 19.354354] systemd-journald[210]: /var/log/journal/8e4cbfea404512ae70096c6202c9a3bf/system.journal: Journal file corrupted, rotating.</div><div><br></div><div>If I change systemd-journaling to volatile storage, erase the persistent storage location logs, reboot, and try to reproduce the problem, I can't. There are some reports of VM images on btrfs being corrupted somehow (although I don't think it's related to balance, I could be wrong), and the solution is to set VM images to nodatacow. So I wonder if there's some behavior of systemd journaling that's similar?</div><div><br></div><div>Bug is here:</div><div><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1011714">https://bugzilla.redhat.com/show_bug.cgi?id=1011714</a></div><div><br></div><div><br></div><div><br></div><div>Chris Murphy</div><br></body></html>