On 06/01/2014 11:07 PM, Mitch Harder wrote:
On Sat, May 31, 2014 at 6:51 PM, Brendan Hide <bren...@swiftspirit.co.za> 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.
The whole file doesn't need to be cow'ed, just the part that you touch.
So old snapshot-aware defrag probably would have saved you quite a bit
of space. Thanks,
Josef
--
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
