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
>
>
next prev parent 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