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?
That is a very good question. I very rarely have mounts without noatime
- and usually only because I hadn't thought of it.
Regards,
Martin
--
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97
--
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
