Austin S. Hemmelgarn posted on Thu, 14 Jan 2016 14:41:27 -0500 as excerpted: > On 2016-01-14 14:26, Liu Bo wrote: >> On Thu, Jan 14, 2016 at 11:46:33AM -0500, Austin S. Hemmelgarn wrote: >>> On 2016-01-14 11:13, James Hogarth wrote: >>>> Finally what's the present situation with regards to defragmentation >>>> and deduplication? Is it safe to turn on autodefrag now when using >>>> snapshots and duperemove? What should the behaviour be with the >>>> proposed 4.5 dedup patches if both inline dedup and autodefrag are >>>> enabled as mount options? >>> I'm not entirely certain how deduplication would interact with any >>> form of defragmentation. I'm pretty certain though that autodefrag >>> does properly handle snapshots, such that the reflinks aren't broken, >>> and it's the original copy that gets any shared extents defragmented >>> into it. >> >> If it refers to snapshot-aware defrag, it's been disabled, so now btrfs >> will not maintain reflinks between snapshots. >> > I was under the impression that autodefrag had been done separately from > the snapshot-aware manually triggered defrag, and that it's always been > snapshot aware. Hugo should really explain as he was the one that said that, but upon looking into it, he found that while he was correct in a sense, his reasoning was a bit narrow, and autodefrag isn't snapshot aware in the wider context. Without attempting to explain his reasoning as I think I sort of understand it but not well enough to try to explain, autodefrag isn't snapshot aware and will break reflinks, but due to $reasons, autodefrag's damage to reflinking apparently isn't as bad as manual defrag. That's the best I can do to explain the situation. In general, autodefrag remains bad for reflinks, but apparently not h***-bad, as manual defrag is. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
