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. -- Replies to list only preferred. -- 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
