On Feb 6, 2014, at 6:01 PM, cwillu <cwi...@cwillu.com> wrote: > 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.
How fast is this state fixed on disk from the time of the snapshot command? Loosely speaking. I'm curious if this is < 1 second; a few seconds; or possibly up to the 30 second default commit interval? And also if it's even related to the commit interval time at all? I'm also curious what happens to files that are presently writing. e.g. I'm writing a 1GB file to subvol A and before it completes I snapshot subvol A into A.1. If I go find the file I was writing to, in A.1, what's its state? Truncated? Or or are in-progress writes permitted to complete if it's a rw snapshot? Any difference in behavior if it's an ro snapshot? Chris Murphy -- 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
