public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Piavlo <piavka@cs.bgu.ac.il>
To: Adrian von Bidder <avbidder@fortytwo.ch>
Cc: TARUISI Hiroaki <taruishi.hiroak@jp.fujitsu.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: snapshot/subvolume removal
Date: Tue, 12 Jan 2010 13:03:53 +0200	[thread overview]
Message-ID: <4B4C5719.7020406@cs.bgu.ac.il> (raw)
In-Reply-To: <201001121012.52665@fortytwo.ch>

Adrian von Bidder wrote:
> Hi,
>
> On Tuesday 12 January 2010 08.08:26 Piavlo wrote:
>   
>> Maintaining snapshot hierarchy by  external application is not reliable
>> and error prone
>> compared to maintaining it withing the btrfs itself,
>> probably by adding the parent treeid field for every  shapshot/subvolume.
>>     
>
> What should, in your opinion, happen if the parent snapshot is deleted?  
> Orphan? Re-parent to parent of parent?
Re-parent to parent of parent.
And if there is no grandparent then  point to itself (like with root
directory).
This hierarchy should be tracked/modifed within same subvolume only - so
each subvolume has it's own snapshots hierarchy.
This would allow, for example, easy rollback of most recent subvolume
state to previous states (probably with btrfsctl)  without maintaining
snapshots hierarchy state in userspace applications.

 Thanks
  Alex
>   I guess depending on application, 
> there may be more than one "right" solution.
>
> cheers
> -- vbi
>
>   


  reply	other threads:[~2010-01-12 11:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-05 21:18 snapshot/subvolume removal Piavlo
2010-01-06  0:30 ` TARUISI Hiroaki
2010-01-06  6:54   ` Adrian von Bidder
2010-01-06  8:33   ` Piavlo
2010-01-08  8:28     ` TARUISI Hiroaki
2010-01-09 22:01       ` Piavlo
2010-01-12  0:48         ` TARUISI Hiroaki
2010-01-12  7:08           ` Piavlo
2010-01-12  8:04             ` TARUISI Hiroaki
2010-01-12  9:12             ` Adrian von Bidder
2010-01-12 11:03               ` Piavlo [this message]
2010-01-10 20:18       ` Chris Mason
2010-01-12  1:12         ` TARUISI Hiroaki

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=4B4C5719.7020406@cs.bgu.ac.il \
    --to=piavka@cs.bgu.ac.il \
    --cc=avbidder@fortytwo.ch \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=taruishi.hiroak@jp.fujitsu.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox