On Sat, May 31, 2014 at 6:51 PM, Brendan Hide <brendan@xxxxxxxxxxxxxxxxx> wrote: > On 2014/05/31 12:00 AM, Martin wrote: >> >> OK... I'll jump in... >> >> On 30/05/14 21:43, Josef Bacik wrote: >>> >>> [snip] >>> >>> Option 1: Only relink inodes that haven't changed since the snapshot was >>> taken. >>> >>> Pros: >>> -Faster >>> -Simpler >>> -Less duplicated code, uses existing functions for tricky operations so >>> less likely to introduce weird bugs. >>> >>> Cons: >>> -Could possibly lost some of the snapshot-awareness of the defrag. If >>> you just touch a file we would not do the relinking and you'd end up >>> with twice the space usage. >> >> [...] >> >> >> Obvious way to go for fast KISS. > > > I second this - KISS is better. > > Would in-band dedupe resolve the issue with losing the "snapshot-awareness > of the defrag"? I figure that if someone absolutely wants everything deduped > efficiently they'd put in the necessary resources (memory/dedicated SSD/etc) > to have in-band dedupe work well. > >> One question: >> >> Will option one mean that we always need to mount with noatime or >> read-only to allow snapshot defragging to do anything? > > When snapshot-aware defrag first came out, I was convinced it was a "must-have" capability for nearly everybody using btrfs. But, the more I look at my work load and common practices with btrfs, the more I am wondering just how often snapshot-aware defrag was actually doing something for me. I use a lot of snapshots. But for the most part, once I touch a file in my current subvolume, the whole file needs to be COW-ed from it's previous version. Now that we have a working sysfs, I wonder if we could implement some counters to track how often snapshot-aware defrag would have run. I might be surprised at how much it was doing. --- Regards, Mitch Harder -- 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
