From: David Sterba <dsterba@suse.cz>
To: Rich Freeman <r-btrfs@thefreemanclan.net>
Cc: Marc Cousin <cousinmarc@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: snapshot destruction making IO extremely slow
Date: Mon, 30 Mar 2015 16:30:58 +0200 [thread overview]
Message-ID: <20150330143058.GJ32051@suse.cz> (raw)
In-Reply-To: <CAGfcS_n1CyDMXdAu6eKuwszz+hBxnHdLpgxwW63TPs9k2zFDbQ@mail.gmail.com>
On Wed, Mar 25, 2015 at 07:38:20AM -0400, Rich Freeman wrote:
> On Wed, Mar 25, 2015 at 6:55 AM, Marc Cousin <cousinmarc@gmail.com> wrote:
> > On 25/03/2015 02:19, David Sterba wrote:
> >> as it reads the pre/post snapshots and deletes them if the diff is
> >> empty. This adds some IO stress.
> >
> > I couldn't find a clear explanation in the documentation. Does it mean
> > that when there is absolutely no difference between two snapshots, one
> > of them is deleted ? And that snapper does a diff between them to
> > determine that ?
> >
>
> It seems like there should be some supported way of doing a diff on
> two btrfs subvolumes.
> The problem is that we don't have any functionality in kernel space to
> do this (that I'm aware of), and we don't expose the necessary
> information to userspace for it to do this smartly (again, as far as
> I'm aware).
> Maybe there would be some way to do it using btrfs send and parsing the output.
If the subvolumes are read-only than the lightweight send (ioctl with
flag bit set BTRFS_SEND_FLAG_NO_FILE_DATA) could be used and I think
this was the expected usecase.
next prev parent reply other threads:[~2015-03-30 14:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-22 8:11 snapshot destruction making IO extremely slow Marc Cousin
2015-03-22 8:23 ` Marc Cousin
2015-03-25 1:19 ` David Sterba
2015-03-25 10:55 ` Marc Cousin
2015-03-25 11:38 ` Rich Freeman
2015-03-30 14:30 ` David Sterba [this message]
2015-03-30 14:25 ` David Sterba
2015-03-30 15:09 ` Marc Cousin
2015-03-31 17:05 ` David Sterba
2015-04-20 9:51 ` Marc Cousin
2015-04-23 15:42 ` Marc Cousin
2017-05-24 8:10 ` Marc Cousin
2017-05-24 8:23 ` Marat Khalili
2017-06-05 8:30 ` Jakob Schürz
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=20150330143058.GJ32051@suse.cz \
--to=dsterba@suse.cz \
--cc=cousinmarc@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=r-btrfs@thefreemanclan.net \
/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.