OmegaPhil posted on Wed, 04 Nov 2015 21:53:09 +0000 as excerpted: > The volume doesn't change hugely over time, so it really ought not to > have broken so quickly - a quick rundown of the storage usage: > > 36% general (small files, some smallish videos) > 24% music 23% pr0n 17% VMs > > But in terms of 'large files changing', it could be the VM disks perhaps > - > I'll move them out, balance, and then back in again, hopefully that'd be > a meaningful test.
VM image files (and large database files, for the same reason) are a bit of a problem on btrfs, and indeed, any COW-based filesystem, since the random rewrite pattern matching that use-case is pretty much the absolute worst-case match for a COW-based filesystem there is. And that would be the worst-case in terms of the unsplit extents issue Hugo was talking about as well. So they may well be the problem, indeed. Since you're not doing snapshotting (which conflicts with this option, with an imperfect workaround), setting nocow on those files may well eliminate the problem, but be aware if you aren't already that (1) nocow does turn off checksumming as well, in ordered to avoid a race that could easily lead to data corruption, and (2) you can't just activate nocow on the existing file and expect it to work, the procedure is a bit more complicated than that, since nocow is only guaranteed to work if it's set at file creation. Detailed instructions for #2 skipped as they've been posted many times, but if you are interested and haven't seen them, ask. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
