Difference between revisions of "Talk:BTRFS Fun"

Revision as of 14:37, 29 May 2011

About this section :

http://docs.funtoo.org/index.php?title=BTRFS_Fun&curid=14792&diff=17917&oldid=17916#Deploying_a_Funtoo_instance_in_a_subvolume_other_than_0_.28should_avoid_the_rsync.29

Can I rewrite it, because it's clear that you don't understand what DestroyFx and I are trying to explain to you.

# fdisk /dev/sda2
....
# mkfs.btrfs /dev/sda2
# mount /dev/sda2 /mnt/funtoo
# btrfs subvolume create /mnt/funtoo /mnt/funtoo/live-vfs-root-20110523
# chroot /mnt/funtoo/live-vfs-root-20110523 /bin/bash

What are you trying to do with that ? Is this an example of installing a Funtoo box inside a subvolume ?

If so, you don't need that :

# fdisk /dev/sda2
....
# mkfs.btrfs /dev/sda2
# mount /dev/sda2 /mnt/funtoo
# cd /mnt/funtoo
# btrfs subvolume create live-vfs-root-20110523
# cd / && umount /mnt/funtoo && mount /dev/sda2 /mnt/funtoo -o subvol=live-vfs-root-20110523
....
# chroot /mnt/funtoo /bin/bash

And about this :

Mount to the no named volume somewhere (e.g. mount -o subvolid=0 /dev/sdX /mnt)

Take a snapshot (remember to check its identification number) of your current subvolume and store it under the non named volume you just have just mounted (btrfs snapshot create / /mnt/before-updating-20110524) -- (Where is the "frontier"? If 0 is monted does its contennts also appear in the taken snashot located on the same volume?)

I'm gonna explain it in my own words.

If you mount -o subvolid=0 /dev/sdx /mnt

When you enter /mnt, you will be able to snapshot whatever subvolume that you want.

So, if you have this :

@subvolid=0
   subvolume home
   subvolume root
   a snapshot

If you run this : btrfs subvolume snapshot / test, you will end with :

  subvolume home
  subvolume root
  a snapshot
  test

Test will contains the data from all the subvolume under the subvolid=0.

But if you run this and you didn't run the first snapshot command :

btrfs subvolume snapshot home test_test, you will end with :

@subvolid=0
   subvolume home
   subvolume root
   a snapshot 
   test_test

test_test will contains only the data from home.

When you mount the subvolid=0, you should never use the / to snapshot, but you should use a specific subvolume instead. That's a BTRFS feature, it's like Logicial Partition inside the Virtual Group stuff if you refer to LVM.

I can even post my suggestion here and you will be free to include them or not inside the page.

<en_francais> 1. Je vais prendre le temps de lire dans le détails tes suggestions plus tard, il y a dedans je pense des idées qui pourraient apporter quelque chose mais je veux veux être certain de bien comprendre ce que tu expliques. Il se peut que je sois passé à côté de certains détails un peu pointus.

2. Il s'agit ici d'un quick workshop qui se veut expliquer dans les grandes lignes la grande philosophie de la chose non d'une procédure détaillée (une procédure est avant un manuel organisationnel, si le datacenter me claque dans les doigt je dois avoir un manuel qui explique comment le remonter OPC dans l'exact qu'il était avant sinistre). Si après avoir lu la chose le monde comprend que BTFS y c'est en gros un système de conteneurs logiques et qu'est-ce que ça peut leur apporter (entre autre s'éviter une réinstall de zéro alors qu'il suffit juste d'inverser 2 conteneurs) tant mieux le but est atteint. Mon objectif n'est pas détailler, chacun a son environnement avec ses propres particularités, aux gens de savoir faire une lecture intelligente et d’adapter la chose à leur contexte. </en_francais>

<en_francais> Je vais écrire un exemple concret et tu verras par la suite. D2 racing </en_francais>

<en_francais> Concernant ta question de frontière pour les snapshots et autres.

Regarde mon expérience

</en_francais>

root@sylvain-VirtualBox:~# mkdir /mnt/backup

root@sylvain-VirtualBox:~# mount /dev/sda5 /mnt/backup/ -o subvolid=0

root@sylvain-VirtualBox:~# cd /mnt/backup/

root@sylvain-VirtualBox:/mnt/backup# ls
@  @home

root@sylvain-VirtualBox:/mnt/backup# btrfs subvolume snapshot @ @live-root
Create a snapshot of '@' in './@live-root'
root@sylvain-VirtualBox:/mnt/backup# ls -la
total 4
dr-xr-xr-x 1 root root  32 1969-12-31 19:00 .
drwxr-xr-x 1 root root  12 2011-05-28 23:14 ..
drwxr-xr-x 1 root root 194 2011-05-22 15:39 @
drwxr-xr-x 1 root root  14 2011-05-22 15:28 @home
drwxr-xr-x 1 root root 194 2011-05-22 15:39 @live-root

root@sylvain-VirtualBox:/mnt/backup# btrfs subvolume snapshot /mnt/backup/ @toute

Create a snapshot of '/mnt/backup/' in './@toute'
root@sylvain-VirtualBox:/mnt/backup# ls
@  @home  @live-root  @toute

root@sylvain-VirtualBox:/mnt/backup# cd @toute/

root@sylvain-VirtualBox:/mnt/backup/@toute# ls
@  @home  @live-root
root@sylvain-VirtualBox:/mnt/backup/@toute# 

Bref, voilà pourquoi on ne devrait pas snapshoter une racine :P, mais bien utiliser les snapshots de subvolumes, car là @toute contient un snapshot d'un snapshot(@live-root):P

---

Effectivement la frontière d'un snapshot (c'est assez évident si on pense 5 secondes mais les notes ne le mentionnent pas encore) est le subvolume dont il est issu donc si tu snapshotes ton subvolume qui en compte 10 autres c'est l'ensemble qui sera "copié" (avec le CoW ce n'est pas un drame côté espace disque). Tes explications sont exactement la raison pour laquelle je mentionne plus loin dans l'article qu'il est préférable de ne pas utiliser le subvolume 0, cependant et à moins que les outil de la distribution ne le prenne en charge bien des gens qui vont essayer BTRFS vont utiliser le subvolume 0 directement. Dans un cas comme dans l'autre ce n'est pas dramatique sauf que le fait de ne pas utiliser directement le subvolume 0 t'évites de devoir procéder manuellement à une copie de fichiers... plus sécuritaire pour le contenu dans un sens :-)