public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
* snapshot creation
@ 2010-01-12 19:24 Sage Weil
  2010-01-12 20:25 ` Chris Mason
  0 siblings, 1 reply; 4+ messages in thread
From: Sage Weil @ 2010-01-12 19:24 UTC (permalink / raw)
  To: chris.mason; +Cc: linux-btrfs

Hi Chris,

What is the motivation behind the two phases of snapshot creation 
(create_pending_snapshot, finish_pending_snapshot)?  Is it just to avoid 
putting a reference to the snap subvol inside the snapped version of the 
subvol (forming a loop)?

If that's the case, I think the problem can be solved in other ways (by 
not following the subvol link if it loops to self, or by also delaying the 
root creation to avoid leaking an unreferenced root).  And the rest of the 
time (when the link is outside the linked-to subvol) committing the root 
and it's reference in one commit.

Unless I'm missing something else?

Thanks-
sage

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: snapshot creation
  2010-01-12 19:24 snapshot creation Sage Weil
@ 2010-01-12 20:25 ` Chris Mason
  2010-01-12 20:47   ` Sage Weil
  0 siblings, 1 reply; 4+ messages in thread
From: Chris Mason @ 2010-01-12 20:25 UTC (permalink / raw)
  To: Sage Weil; +Cc: linux-btrfs

On Tue, Jan 12, 2010 at 11:24:39AM -0800, Sage Weil wrote:
> Hi Chris,
> 
> What is the motivation behind the two phases of snapshot creation 
> (create_pending_snapshot, finish_pending_snapshot)?  Is it just to avoid 
> putting a reference to the snap subvol inside the snapped version of the 
> subvol (forming a loop)?
> 
> If that's the case, I think the problem can be solved in other ways (by 
> not following the subvol link if it loops to self, or by also delaying the 
> root creation to avoid leaking an unreferenced root).  And the rest of the 
> time (when the link is outside the linked-to subvol) committing the root 
> and it's reference in one commit.
> 
> Unless I'm missing something else?

Part of the problem is that we want to make sure we have a consistent
view of a given root.  So if we tell snapshot abc to point to a specific
root block, the reference that gets taken and all the cow rules get
complex in a hurry.

I'm guessing that you want to do snapshot creation without forcing a
commit?

-chris


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: snapshot creation
  2010-01-12 20:25 ` Chris Mason
@ 2010-01-12 20:47   ` Sage Weil
  2010-01-13 14:44     ` Chris Mason
  0 siblings, 1 reply; 4+ messages in thread
From: Sage Weil @ 2010-01-12 20:47 UTC (permalink / raw)
  To: Chris Mason; +Cc: linux-btrfs

On Tue, 12 Jan 2010, Chris Mason wrote:

> On Tue, Jan 12, 2010 at 11:24:39AM -0800, Sage Weil wrote:
> > Hi Chris,
> > 
> > What is the motivation behind the two phases of snapshot creation 
> > (create_pending_snapshot, finish_pending_snapshot)?  Is it just to avoid 
> > putting a reference to the snap subvol inside the snapped version of the 
> > subvol (forming a loop)?
> > 
> > If that's the case, I think the problem can be solved in other ways (by 
> > not following the subvol link if it loops to self, or by also delaying the 
> > root creation to avoid leaking an unreferenced root).  And the rest of the 
> > time (when the link is outside the linked-to subvol) committing the root 
> > and it's reference in one commit.
> > 
> > Unless I'm missing something else?
> 
> Part of the problem is that we want to make sure we have a consistent
> view of a given root.  So if we tell snapshot abc to point to a specific
> root block, the reference that gets taken and all the cow rules get
> complex in a hurry.
> 
> I'm guessing that you want to do snapshot creation without forcing a
> commit?

Actually I just want the snapshot AND the reference to it to commit at 
once.  (Currently, you create a snap, a commit happens, and then you still 
need to sync one more time or it can get orphaned.)  I posted a patch a 
few weeks back that did that, but it wasn't clear to me why the snapshot 
link was delayed in the first place.  If it's loop avoidance, maybe we can 
at least avoid that in the case where the reference isn't in the same root 
it refers to...

sage

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: snapshot creation
  2010-01-12 20:47   ` Sage Weil
@ 2010-01-13 14:44     ` Chris Mason
  0 siblings, 0 replies; 4+ messages in thread
From: Chris Mason @ 2010-01-13 14:44 UTC (permalink / raw)
  To: Sage Weil; +Cc: linux-btrfs

On Tue, Jan 12, 2010 at 12:47:22PM -0800, Sage Weil wrote:
> On Tue, 12 Jan 2010, Chris Mason wrote:
> 
> > On Tue, Jan 12, 2010 at 11:24:39AM -0800, Sage Weil wrote:
> > > Hi Chris,
> > > 
> > > What is the motivation behind the two phases of snapshot creation 
> > > (create_pending_snapshot, finish_pending_snapshot)?  Is it just to avoid 
> > > putting a reference to the snap subvol inside the snapped version of the 
> > > subvol (forming a loop)?
> > > 
> > > If that's the case, I think the problem can be solved in other ways (by 
> > > not following the subvol link if it loops to self, or by also delaying the 
> > > root creation to avoid leaking an unreferenced root).  And the rest of the 
> > > time (when the link is outside the linked-to subvol) committing the root 
> > > and it's reference in one commit.
> > > 
> > > Unless I'm missing something else?
> > 
> > Part of the problem is that we want to make sure we have a consistent
> > view of a given root.  So if we tell snapshot abc to point to a specific
> > root block, the reference that gets taken and all the cow rules get
> > complex in a hurry.
> > 
> > I'm guessing that you want to do snapshot creation without forcing a
> > commit?
> 
> Actually I just want the snapshot AND the reference to it to commit at 
> once.  (Currently, you create a snap, a commit happens, and then you still 
> need to sync one more time or it can get orphaned.)  I posted a patch a 
> few weeks back that did that, but it wasn't clear to me why the snapshot 
> link was delayed in the first place.  If it's loop avoidance, maybe we can 
> at least avoid that in the case where the reference isn't in the same root 
> it refers to...

Ok, it's not loop avoidance, its just keeping the whole tree consistent.
I'll pick up the patch from you.

-chris


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-01-13 14:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-12 19:24 snapshot creation Sage Weil
2010-01-12 20:25 ` Chris Mason
2010-01-12 20:47   ` Sage Weil
2010-01-13 14:44     ` Chris Mason

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox