All of lore.kernel.org
 help / color / mirror / Atom feed
From: TARUISI Hiroaki <taruishi.hiroak@jp.fujitsu.com>
To: kreijack@gmail.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs-progs: New utility to swap subvolumes
Date: Mon, 04 Jan 2010 09:49:44 +0900	[thread overview]
Message-ID: <4B413B28.7090604@jp.fujitsu.com> (raw)
In-Reply-To: <4B380C22.4010809@jp.fujitsu.com>

Buon anno, Goffredo.

Taking snapshot in btrfs is very easy, but handling snapshots is
very confusing. So, we must make a rule of snapshotting such as
your proposal, which seems to me very good and useful.
If rules like this are forced regardless of operator's preference,
this utility may become a deadwood.

Identification with non-filesystem-related identifier seems to me
a good idea. But because subvolume is unique idea in btrfs,
identifying subvolumes can be unique, too.
Subvolume ID represents some information belong to subvolume
(like snapshot date/time... not data which subvolume contains),
and not variable. It becomes useful information/identifier
to handle snapshots although it's not friendly to human being.

Regards,
taruisi

>Hi Taruisi,
>
>On Monday 28 December 2009, TARUISI Hiroaki wrote:
>[...]
>
>> We can swap subvolumes regardless of mounted-subvolume. (only
>> when we mount other subvolume than fs tree)
>I resolved this kind of problem as described in my previous email ([RFC]
>proposal for a btrfs filesystem layout - 20/Nov/2009): I used a sub-volume as
>root of my system, but I mounted also the root of the btrfs filesystem for
>handling the sub-volumes under "/var/btrfs". It work quiet well:
>1) I can swap the sub-volumes only with the mv commands
>2) I can switch to an old snapshot of the root at boot time, because my
>scripts update the grub entries with the list of the valid snapshots
>3) I can switch permanently two sub-volumes exchanging their names
>4) I can remove a sub-volume quite easily
>
>> And, because we can identify snapshot (its date or target subvol)
>> with subvolume ID, it is suitable to swap with ID.
>Why you want to to identify a sub-volume with its id ?
>I like the idea to identify a sub-volumes with an identifier which is not
>file-system related. To me the fact that a sub-volume is identified with its
>"mount point" seems to me a limit instead that an advantage. But it seems that
>I am alone to thinking that :-(
>So I am curious about your reasons.
>
>BR
>Goffredo
>
>--
>gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
>Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512


  parent reply	other threads:[~2010-01-04  0:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-24  2:17 btrfs-progs: New utility to swap subvolumes TARUISI Hiroaki
2009-12-24  2:18 ` [PATCH] " TARUISI Hiroaki
2009-12-27 20:23 ` Goffredo Baroncelli
2009-12-28  1:38   ` TARUISI Hiroaki
2009-12-28 19:08     ` Goffredo Baroncelli
2010-01-04  0:49     ` TARUISI Hiroaki [this message]
2010-01-04 17:20       ` Goffredo Baroncelli
2010-01-06  0:09         ` TARUISI Hiroaki
2010-01-06  7:56           ` Goffredo Baroncelli
     [not found]             ` <4B4450C0.3050607@cs.bgu.ac.il>
2010-01-06 20:21               ` Goffredo Baroncelli

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=4B413B28.7090604@jp.fujitsu.com \
    --to=taruishi.hiroak@jp.fujitsu.com \
    --cc=kreijack@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.