On 18 October 2015 at 16:46, Duncan <1i5t5.dun...@cox.net> wrote: > Xavier Gnata posted on Sat, 17 Oct 2015 18:36:32 +0200 as excerpted: > >> Hi, >> >> On a desktop equipped with an ssd with one 100GB virtual image used >> frequently, what do you recommend? >> 1) nothing special, it is all fine as long as you have a recent kernel >> (which I do) >> 2) Disabling copy-on-write for just the VM image directory. >> 3) autodefrag as a mount option. >> 4) something else. >> >> I don't think this usecase is well documented therefore I asked this >> question.
[snip] > So ssd or spinning rust, there's serious conflicts between nocow and > snapshotting that really must be taken into consideration if you're > planning to both snapshot and nocow. This is all spot on advice, but I just wanted to chime in to mention: I've been experimenting with - - Active working copy of VM image files are hosted on non-btrfs filesystems - Regular scheduled rsync --inplace onto a btrfs subvol copy of the file that *is* snapshotted and part of regular send/receive runs. rsync --inplace does what it says on the tin: it just rewrites those parts of a file which need to be updated. Thus it only gets written to once prior to each snapshot run, rather than continuously. So the theory is that I can retain CoW storage efficiency (hold lots of snapshots cheaply) but still keep decent performance (by running the active, in-use working copies outside of my normal snapshotted btrfs filesystems). The cost is obviously more filesystems than you'd normally have to run, more complex disaster recovery, not to mention storage sizing has to accommodate a working copy on a separate fs to the archived copies. Plus, this rsync approach has noticeably bigger I/O overhead than btrfs send/receive, although in my environment nobody is noticing. -- 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
