On Thu, Feb 6, 2014 at 6:32 PM, Kai Krakow <hurikhan77+bt...@gmail.com> wrote: > Duncan <1i5t5.dun...@cox.net> schrieb: > >>> Ah okay, that makes it clear. So, actually, in the snapshot the file is >>> still nocow - just for the exception that blocks being written to become >>> unshared and relocated. This may introduce a lot of fragmentation but it >>> won't become worse when rewriting the same blocks over and over again. >> >> That also explains the report of a NOCOW VM-image still triggering the >> snapshot-aware-defrag-related pathology. It was a _heavily_ auto- >> snapshotted btrfs (thousands of snapshots, something like every 30 >> seconds or more frequent, without thinning them down right away), and the >> continuing VM writes would nearly guarantee that many of those snapshots >> had unique blocks, so the effect was nearly as bad as if it wasn't NOCOW >> at all! > > The question here is: Does it really make sense to create such snapshots of > disk images currently online and running a system. They will probably be > broken anyway after rollback - or at least I'd not fully trust the contents. > > VM images should not be part of a subvolume of which snapshots are taken at > a regular and short interval. The problem will go away if you follow this > rule. > > The same applies to probably any kind of file which you make nocow - e.g. > database files. Most of those file implement their own way of transaction > protection or COW system, e.g. look at InnoDB files. Neither they gain > anything from using IO schedulers (because InnoDB internally does block > sorting and prioritizing and knows better, doing otherwise even hurts > performance), nor they gain from file system semantics like COW (because it > does its own transactions and atomic updates and probably can do better for > its use case). Similar applies to disk images (imagine ZFS, NTFS, ReFS, or > btrfs images on btrfs). Snapshots can only do harm here (the only > "protection" use case would be to have a backup, but snapshots are no > backups), and COW will probably hurt performance a lot. The only use case is > taking _controlled_ snapshots - and doing it all 30 seconds is by all means > NOT controlled, it's completely undeterministic.
If the database/virtual machine/whatever is crash safe, then the atomic state that a snapshot grabs will be useful. -- 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
