On 02/11/2018 05:15 PM, Ellis H. Wilson III wrote: > Thanks Hans. Sorry for the top-post, but I'm boiling things down here > so I don't have a clear line-item to respond to. The take-aways I see > here to my original queries are: > > 1. Nobody has done a thorough analysis of the impact of snapshot > manipulation WITHOUT qgroups enabled on foreground I/O performance > 2. Nobody has done a thorough analysis of the impact of snapshot > manipulation WITH qgroups enabled on foreground I/O performance
It's more that there is no simple list of clear-cut answers that apply to every possible situation and type/pattern of work that you can throw at a btrfs filesystem. > 3. I need to look at the code to understand the interplay between > qgroups, snapshots, and foreground I/O performance as there isn't > existing architecture documentation to point me to that covers this Well, the excellent write-up of Qu this morning shows some explanation from the design point of view. > 4. I should be cautioned that CoW in BTRFS can exhibit pathological (if > expected) capacity consumption for very random-write-oriented datasets > with or without snapshots, and nocow (or in my case transparently > absorbing and coalescing writes at a higher tier) is my friend. nocow only keeps the cows on a distance as long as you don't start snapshotting (or cp --reflink) those files... If you take a snapshot, then you force btrfs to keep the data around that is referenced by the snapshot. So, that means that every next write will be cowed once again, moo, so small writes will be redirected to a new location, causing fragmentation again. The second and third write can go in the same (new) location of the first new write, but as soon as you snapshot again, this happens again. > 5. I should be cautioned that CoW is broken across snapshots when > defragmentation is run. > > I will update a test system to the most recent kernel and will perform > tests to answer #1 and #2. I will plan to share it when I'm done. If I > have time to write-up my findings for #3 I will similarly share that. > > Thanks to all for your input on this issue. Have fun! -- Hans van Kranenburg -- 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
