Difference between revisions of "Talk:BTRFS Fun"
| Line 77: | Line 77: | ||
I can even post my suggestion here and you will be free to include them or not inside the page. | 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> | ||
Revision as of 13:26, 26 May 2011
About this section :
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>
