Skip to contentSkip to conversation

btrfs-progs: New utility to swap subvolumes

PATCH New TARUISI Hiroaki 2 participants 10 messages Dec 24, 2009 – Jan 6, 2010 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

New utility(btrfsrevert) added to swap subvolumes.

With this utility, a subvolume (Source Subvolume) takes place of another subvolume (Target Subvolume), and target subvolume goes under hidden directory(".old_trees") in filesystem root(fs tree, tree id=5), and its name is expanded with random UUID.

This utility cannot operate mounted filesystem. This is only for unmounted device.
And this utility also cannot operate filesystem root. For now, if we want to swap filesystem root, we can use btrfsctl with Josef Bacik's patch. I wonder which is better, integrating 'root swap' ioctl or not supporting 'root swap' as for this utility...

A patch follows this mail.

man-page-like description and examples are as follows.

NAME
btrfsrevert - swap subvolumes.

SYNOPSIS
btrfsrevert -s source_subvolume -t target_subvolume device

OPTIONS
-s source subvolume
Specify subvolume number which replace target subvolume.
-t target subvolume
Specify subvolume number which is replaced by source subvolume.

device
Specify target device which is not mounted.

SAMPLES

       Consider two subvolumes 'target'(id=256) and 'source'(id=300)
       exist in filesystem root.
           / +
             +- 'target' (id=256)
             +- 'source' (id=300)

       In this case, following command swaps subvolume,

          # btrfsrevert -s 300 -t 256 /dev/hda1

       like this.
           / +
             +- 'target' (id=300)
             |
             +- '.old_tree'
                 +- 'target_[random uuid]' (id=256)

            A subvolume(id:256) is replaced with a subvolume(id:300),
            and replaced subvolume(id:256) goes to .old_trees directory.

Regards,
taruisi

#1 lore raw

PATCH 1/1 btrfs-progs: New utility to swap subvolumes

Add btrfsrevert utility to swap subvolumes.

---
 Makefile      |    5
 btrfsrevert.c |  778 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 782 insertions(+), 1 deletion(-)
Makefile +4 -1
Index: b/Makefile
===================================================================
@@ -17,7 +17,7 @@ bindir = $(prefix)/bin
 LIBS=-luuid
 
 progs = btrfsctl mkfs.btrfs btrfs-debug-tree btrfs-show btrfs-vol btrfsck \
-	btrfs-map-logical
+	btrfs-map-logical btrfsrevert
 
 # make C=1 to enable sparse
 ifdef C
@@ -63,6 +63,9 @@ btrfs-map-logical: $(objects) btrfs-map-
 btrfs-image: $(objects) btrfs-image.o
 	gcc $(CFLAGS) -o btrfs-image $(objects) btrfs-image.o -lpthread -lz $(LDFLAGS) $(LIBS)
 
+btrfsrevert: $(objects) btrfsrevert.o
+	gcc $(CFLAGS) -o btrfsrevert $(objects) btrfsrevert.o $(LDFLAGS) $(LIBS)
+
 dir-test: $(objects) dir-test.o
 	gcc $(CFLAGS) -o dir-test $(objects) dir-test.o $(LDFLAGS) $(LIBS)
 
btrfsrevert.c new file +778 -0

778 lines not on this page · raw message

#2 lore raw
In reply to TARUISI Hiroaki
Quoted 6 lines · TARUISI Hiroaki

New utility(btrfsrevert) added to swap subvolumes.

With this utility, a subvolume (Source Subvolume) takes place of another subvolume (Target Subvolume), and target subvolume goes under hidden directory(".old_trees") in filesystem root(fs tree, tree id=5), and its name is expanded with random UUID.

Hi Taruisi,

which is the supposed goal of this program ? If I understand correctly "btrfsrevert" renames subvolumes. But we can rename a subvolume using the mv command. So "btrfsrevert" may be simulated with a couple of 'mv' command:

# btrfsrevert -s vola-id -t volb-id /dev/sdX

is equivalent to

# mount /dev/sdX/ /mnt  	# only needed if the filesystem is un-mounted
# mkdir /mnt/.old_trees
# mv /mnt/volb /mnt/.old_trees/volb.<random-number>
# mv /mnt/vola /mnt/volb
# umount /mnt               

Is right ? And moreover btrfsrevert has the limit that the file-system shall not be mounted...

On the plus side of btrfsrevert, I can "swap" volumes without having the btrfs module loaded ...

BR
G.Baroncelli

Quoted 59 lines

This utility cannot operate mounted filesystem. This is only for unmounted device.
And this utility also cannot operate filesystem root. For now, if we want to swap filesystem root, we can use btrfsctl with Josef Bacik's patch. I wonder which is better, integrating 'root swap' ioctl or not supporting 'root swap' as for this utility...

A patch follows this mail.

man-page-like description and examples are as follows.

NAME
btrfsrevert - swap subvolumes.

SYNOPSIS
btrfsrevert -s source_subvolume -t target_subvolume device

OPTIONS
-s source subvolume
Specify subvolume number which replace target subvolume.
-t target subvolume
Specify subvolume number which is replaced by source subvolume.

device
Specify target device which is not mounted.

SAMPLES

       Consider two subvolumes 'target'(id=256) and 'source'(id=300)
       exist in filesystem root.
           / +
             +- 'target' (id=256)
             +- 'source' (id=300)

       In this case, following command swaps subvolume,

          # btrfsrevert -s 300 -t 256 /dev/hda1

       like this.
           / +
             +- 'target' (id=300)
             |
             +- '.old_tree'
                 +- 'target_[random uuid]' (id=256)

            A subvolume(id:256) is replaced with a subvolume(id:300),
            and replaced subvolume(id:256) goes to .old_trees directory.

Regards,
taruisi

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 2 lines
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512
#3 lore raw

Thank you for your mail.

I intended to create a swap utility including root subvolume. That was the goal. Swapping root subvolume is not implemented yet...

For now, as you say, in some cases this utility does simple mv commands, but in some cases, it has some advantages.

We can swap subvolumes regardless of mounted-subvolume. (only when we mount other subvolume than fs tree)
And, because we can identify snapshot (its date or target subvol) with subvolume ID, it is suitable to swap with ID.

Regards,
taruisi

Quoted 96 lines · Goffredo Baroncelli
Quoted 6 lines · TARUISI Hiroaki

New utility(btrfsrevert) added to swap subvolumes.

With this utility, a subvolume (Source Subvolume) takes place of another subvolume (Target Subvolume), and target subvolume goes under hidden directory(".old_trees") in filesystem root(fs tree, tree id=5), and its name is expanded with random UUID.

Hi Taruisi,

which is the supposed goal of this program ? If I understand correctly "btrfsrevert" renames subvolumes. But we can rename a subvolume using the mv command. So "btrfsrevert" may be simulated with a couple of 'mv' command:

# btrfsrevert -s vola-id -t volb-id /dev/sdX

is equivalent to

# mount /dev/sdX/ /mnt  	# only needed if the filesystem is un-mounted
# mkdir /mnt/.old_trees
# mv /mnt/volb /mnt/.old_trees/volb.<random-number>
# mv /mnt/vola /mnt/volb
# umount /mnt               

Is right ? And moreover btrfsrevert has the limit that the file-system shall not be mounted...

On the plus side of btrfsrevert, I can "swap" volumes without having the btrfs module loaded ...

BR
G.Baroncelli

Quoted 59 lines

This utility cannot operate mounted filesystem. This is only for unmounted device.
And this utility also cannot operate filesystem root. For now, if we want to swap filesystem root, we can use btrfsctl with Josef Bacik's patch. I wonder which is better, integrating 'root swap' ioctl or not supporting 'root swap' as for this utility...

A patch follows this mail.

man-page-like description and examples are as follows.

NAME
btrfsrevert - swap subvolumes.

SYNOPSIS
btrfsrevert -s source_subvolume -t target_subvolume device

OPTIONS
-s source subvolume
Specify subvolume number which replace target subvolume.
-t target subvolume
Specify subvolume number which is replaced by source subvolume.

device
Specify target device which is not mounted.

SAMPLES

       Consider two subvolumes 'target'(id=256) and 'source'(id=300)
       exist in filesystem root.
           / +
             +- 'target' (id=256)
             +- 'source' (id=300)

       In this case, following command swaps subvolume,

          # btrfsrevert -s 300 -t 256 /dev/hda1

       like this.
           / +
             +- 'target' (id=300)
             |
             +- '.old_tree'
                 +- 'target_[random uuid]' (id=256)

            A subvolume(id:256) is replaced with a subvolume(id:300),
            and replaced subvolume(id:256) goes to .old_trees directory.

Regards,
taruisi

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 1 line
taruisi
#4 lore raw

Hi Taruisi,

On Monday 28 December 2009, TARUISI Hiroaki wrote:
[...]

Quoted 2 lines

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

Quoted 2 lines

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

Signature · 2 lines
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512
#5 lore raw
In reply to TARUISI Hiroaki

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

Quoted 32 lines

Hi Taruisi,

On Monday 28 December 2009, TARUISI Hiroaki wrote:
[...]

Quoted 2 lines

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

Quoted 2 lines

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

#6 lore raw
Quoted 1 line · TARUISI Hiroaki

Buon anno, Goffredo.

あけまして おめでとう Taruisi,

(I hope that happy new year is correctly written)

Quoted 6 lines

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.

I detailed this idea in this article

http://kreijack.blogspot.com/2010/01/linux-btrfs-example-of-layout.html

BR
G.Baroncelli

Signature · 2 lines
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512
#7 lore raw

Thanks for your greetings.

I read your article, and could follow your idea, which looks very practical rule to me.
But we may need some application which support to create or maintain these rules because the relation mount point and subvolumes and snapshots gets complicated as number of subvolumes increases.

Regards,
taruisi

Quoted 19 lines · Goffredo Baroncelli
Quoted 1 line · TARUISI Hiroaki

Buon anno, Goffredo.

あけまして おめでとう Taruisi,

(I hope that happy new year is correctly written)

Quoted 6 lines

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.

I detailed this idea in this article

http://kreijack.blogspot.com/2010/01/linux-btrfs-example-of-layout.html

BR
G.Baroncelli

Signature · 1 line
taruisi
#8 lore raw
Quoted 7 lines · TARUISI Hiroaki

Thanks for your greetings.

I read your article, and could follow your idea, which looks very practical rule to me.
But we may need some application which support to create or maintain these rules because the relation mount point and subvolumes and snapshots gets complicated as number of subvolumes increases.

I wrote a little script which handle the snapshot creation/deleting/listing and grub config file update.

This script supposing the layout which I discussed

- under /var/btrfs is mounter the real root btrfs filesystem
- under the real root file-system there are the snapshots and the root of the system (rootfs)
- in /var/btrfs/snaplist.txt there is the list of snaphsot
- in /boot/grub/menu.lst there is the grub configuration

In you are interested, I can send you.

BR
Goffredo

Quoted 26 lines

Regards,
taruisi

Quoted 19 lines · Goffredo Baroncelli
Quoted 1 line · TARUISI Hiroaki

Buon anno, Goffredo.

あけまして おめでとう Taruisi,

(I hope that happy new year is correctly written)

Quoted 6 lines

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.

I detailed this idea in this article

http://kreijack.blogspot.com/2010/01/linux-btrfs-example-of-layout.html

BR
G.Baroncelli

Signature · 2 lines
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <[email protected]>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512

A message that is not in the archive (sent off-list or not yet received): [email protected]

#10 lore raw

Hello,

here [*] you can find my script.
----> Please pay attention to the fact that it is only tested on my *ubuntu* box. <----

The program has 4 main commands:

$ ./snapmng.sh
        snapmng.sh [-n] create <snapname> [<comment>]   Create a new snapshot.
        snapmng.sh list                                 List the  snapshots.
        snapmng.sh [-n] delete <snapname>               Delete a snapshot.
        snapmng.sh update-grub                          Update grub menulist.
        snapmng.sh help                                 Show help (this).

If the switch '-n' is passed, then 'create' and 'delete' commands don't update the grub menu.
If <snapname> is equal to '.' in the 'create' command, the name is generated automatically like snap-YYYYMMDD.

** list
This is the simplest; this function lists the snapshot on the basis of the content of the file /var/btrfs/snaplist.txt

** update-grub
This is the most triky function. This function update the grub menu on the basis of the snapshot contained in the /var/btrfs/snaplist.txt.

The first entry of the grub menu is extracted. Then for every snapshots this entry is added to the end of the "/boot/grub/menu.lst", replacing "subvol=rootfs" with "subvol=<snapshotname>".
These entries are delimited by the two following rows:

### BEGIN BTRFS SNAPSHOT ITEMS
[...]
### END BTRFS SNAPSHOT ITEMS

So it is possible to update the "/boot/grub/menu.lst" file without affecting the other entries.

** create
this command creates a new snapshot and update the grub config file. If the switch "-n" is passed the menu.lst file will not be updated.

** delete
this command deletes a snapshot and update the grub config file. If the switch "-n" is passed the menu.lst file will not be updated

I repeat the btrfs filesystem layout.

Nomenclature:
-- root of system -> where there are the typical directories/files like /bin, /sbin /usr /etc...
-- root of the (btrfs) file-system -> where there are the snapshots or subvolumes

Under root of the filesystem there are the *subvolume* for the root of the system. Its name is "rootfs", and contains the standard filesystem (/bin /usr /sbin /etc ... ).
The snapshot of the root of the system is still under /

So the filesystem layout is

/
\

  +--rootfs	system root (subvolume)
  |    \
  |     +--/bin
  |     +--/sbin
  |     +--/etc
  |     +--/usr
  |	    [...]
  +--snap-123      snapshot of the system root #123
  |    \
  |     +--/bin
  |     +--/sbin
  |	    [...]
  +--snap-3456     snapshot of the system root #3456
  |    \
  |     +--/bin
  |     +--/sbin
  |	    [...]

At the boot time as root is not mounted the root of the filesystem, but the subvolume/snapshot "rootfs"

Tipically in my ubuntu the grub entry is

	title           Ubuntu 9.10, kernel 2.6.31-17-generic
	root            (hd0,0)
	kernel          /vmlinuz root=/dev/sdX ro rootflags=subvol=rootfs 
	initrd          /initrd.img-2.6.31-17-generic

quiet

Note the part "rootflags=subvol=rootfs".
Pay attention that the prefix "rootflags" is debian related (it should works for both debian and ubuntu). For examples for Fedora, the prefix would be "rootfsflags".

for administration purpose the root of the btrfs filesystem is mounted under /var/btrfs. In my /etc/fstab there are the following lines:

  /dev/sdX  /           btrfs  subvol=rootfs,errors=remount-ro,noatime  0 1
  /dev/sdX  /var/btrfs  btrfs  subvol=.,errors=remount-ro,noatime       0 1

[*] http://cassiopea.homelinux.net/git/?p=snapmng/.git;a=summary

BR
Goffredo

Quoted 16 lines · you (Piavlo)

Hi Goffredo,

I'm interested in your script.

BTW great article - seems to be very similar to how opensolaris handles boot environments with zfs.

Also I think it's better to keep the /boot as separate btrfs subvolume - in order to have only one
instance of /boot/grub/menu.lst and kernels independent of all the rootfs snapshots - of course this will
work only of grub2 can be told to look for /boot/grub/menu.lst under the btrfs boot subvolume - otherwise
we need to store the /boot as normal directory under the root subvolume of the btrfs filesystem.

Quoted 20 lines

I've implemented your idea , but currently the /boot is stored under ext3 with legacy-grub.
Need to check it will work with boot inside btrfs with grub2.

Thanks
Alex

Quoted 12 lines · Goffredo Baroncelli
Quoted 8 lines · TARUISI Hiroaki

Thanks for your greetings.

I read your article, and could follow your idea, which looks very practical rule to me.
But we may need some application which support to create or maintain these rules because the relation mount point and subvolumes and snapshots gets complicated as number of subvolumes increases.

I wrote a little script which handle the snapshot

creation/deleting/listing

Quoted 6 lines
Quoted 6 lines

and grub config file update.

This script supposing the layout which I discussed

- under /var/btrfs is mounter the real root btrfs filesystem
- under the real root file-system there are the snapshots and the root of

the

Quoted 12 lines
Quoted 10 lines

system (rootfs)
- in /var/btrfs/snaplist.txt there is the list of snaphsot
- in /boot/grub/menu.lst there is the grub configuration

In you are interested, I can send you.

BR
Goffredo

Signature · 2 lines
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512