All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fb.com>
To: Martin <m_btrfs@ml1.co.uk>, <linux-btrfs@vger.kernel.org>
Subject: Re: What to do about snapshot-aware defrag
Date: Mon, 2 Jun 2014 09:22:01 -0400	[thread overview]
Message-ID: <538C7A79.8070407@fb.com> (raw)
In-Reply-To: <lmav1p$ih7$1@ger.gmane.org>

On 05/30/2014 06:00 PM, Martin wrote:
> OK... I'll jump in...
>
> On 30/05/14 21:43, Josef Bacik wrote:
>> Hello,
>>
>> TL;DR: I want to only do snapshot-aware defrag on inodes in snapshots
>> that haven't changed since the snapshot was taken.  Yay or nay (with a
>> reason why for nay)
>
> [...]
>>
>> === Summary and what I need ===
>>
>> 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.
>
>
> One question:
>
> Will option one mean that we always need to mount with noatime or
> read-only to allow snapshot defragging to do anything?
>

Yeah atime would screw this up, I hadn't thought of that.  With that 
being the case I think the only option is to keep the old behavior, we 
don't want to screw up stuff like this just because users used a backup 
program on their snapshot and didn't use noatime.  Thanks,

Josef


  parent reply	other threads:[~2014-06-02 13:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-30 20:43 What to do about snapshot-aware defrag Josef Bacik
2014-05-30 22:00 ` Martin
2014-05-31 23:51   ` Brendan Hide
2014-06-01  1:52     ` Duncan
2014-06-02  3:07     ` Mitch Harder
2014-06-02 13:19       ` Josef Bacik
2014-06-02 13:22   ` Josef Bacik [this message]
2014-06-03 23:54     ` Martin
2014-06-04  9:19       ` Erkki Seppala
2014-06-04 13:15         ` Martin
2014-06-04 19:33           ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=538C7A79.8070407@fb.com \
    --to=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=m_btrfs@ml1.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.