On Wed, Aug 16, 2017 at 09:53:57AM -0400, Austin S. Hemmelgarn wrote: > > So apart from some central DBs for the storage management system > > itself, CoW is mostly no issue for us. > > But I've talked to some friend at the local super computing centre and > > they have rather general issues with CoW at their virtualisation > > cluster. > > Like SUSE's snapper making many snapshots leading the storage images of > > VMs apparently to explode (in terms of space usage). > SUSE is pathological case of brain-dead defaults. Snapper needs to > either die or have some serious sense beat into it. When you turn off > the automatic snapshot generation for everything but updates and set the > retention policy to not keep almost everything, it's actually not bad at > all.
The defaults for timeline are really bad, the partition is almost never big enough to hold 10 months worth of data updates, not to say 10 years. A rolling distro can fill the space even with the daily or weeky settings set to low numbers. But certain people had different oppinion and I was not successful to change that. The least I did was to document some of the usecases and the hints that could allow one to have a bit more understanding of the effects. https://github.com/kdave/btrfsmaintenance#tuning-periodic-snapshotting > > For some of their storage backends there simply seem to be no de- > > duplication available (or other reasons that prevent it's usage). > If the snapshots are being CoW'ed, then dedupe won't save them any > space. Also, nodatacow is inherently at odds with reflinks used for dedupe. > > > > From that I'd guess there would be still people who want the nice > > features of btrfs (snapshots, checksumming, etc.), while still being > > able to nodatacow in specific cases. > Snapshots work fine with nodatacow, each block gets CoW'ed once when > it's first written to, and then goes back to being NOCOW. The only > caveat is that you probably want to defrag either once everything has > been rewritten, or right after the snapshot. -- 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
