Re: Questions LVM & co

Pàgina inicial

Reply to this message
Autor: Olivier Allard-Jacquin
Data:  
A: ML Guilde
Assumpte: Re: Questions LVM & co
    Bonjour,

    je reviens sur la liste afin de faire part de mes tests sur unionfs,
aufs, funionfs, et unionfs-duse . Merci à Olivier et à Frédéric pour
leur pistes.


Rappel: L'idée est "fusionner" deux partitions distinctes (venant ou non
de deux disques différents), en un unique point de montage. Et ce, afin
que l'utilisateur final puisse disposer en un répertoire unique de la
capacité de stockage des deux partitions.

Olivier Allard-Jacquin a écrit :
>     Bonjour,

>
>     j'ai (*) deux disques que j'aimerai "fusionner" ensemble afin de créer
> un "gros" espace de stockage.
> - Sur le 1er disque, il y a XXX Go non partitionné.
> - Et sur le 2nd disque, tout l'espace est vide (YYY Go).

>
>     Je me suis intéressé à LVM http://doc.ubuntu-fr.org/lvm ,
> http://www.lea-linux.org/cached/index/Leapro-pro_sys-lvm.html , qui
> semble pouvoir s'occuper de cela.

>
>     Mais ma question est la suivante : Que se passe t'il si un des deux
> support physique devient défectueux (par exemple, si le 1er disque dur
> tombe en panne,  et que je perds donc les XXX Go). Est-ce que je perds
> aussi toutes les données du 2nd volume (YYY Go) ? Ou est-ce qu'il y a
> quelque chose de récupérable ?

>
>     Si j'utilise un système de fichier de type ext3 au-dessus de LVM,
> est-ce que des outils du type PhotoRec (
> http://www.cgsecurity.org/wiki/PhotoRec_FR ) peuvent récupérer quelque
> chose ?

>
>     Plus globalement : Quelles sont les solutions de type LVM (qu'y a t'il
> d'autre ?) qui permettent de ne pas tout perdre en cas de panne d'un
> support physique ?

>
>     Merci d'avance,

>
>     Cordialement,

>
>                             Olivier

>
> (*): J'utilise une Debian Testing sur un Sparc64, mais je ne pense pas
> que les réponses soient liés à la distribution ou au type de processeur


    Les tests ont été fait sur une Debian Lenny/Testing (processeur x86),
avec un disque dur externe USB (/dev/sdb).


    6 partitions ont été créés sur le disque : /dev/sdb5 à /dev/sdb10.


    Chaque partitions est formaté en ext3.




++++ UnionFS : http://unionfs.filesystems.org/ ++++

    Au jours où j'écris ces lignes, unionfs n'est pas disponible dans
Debian Lenny/Testing. Je pense c'est un choix du packageur du kernel
Debian (c'est un module du kernel). Il n'y aura donc pas de test...




++++ AUFS : http://aufs.sourceforge.net/ ++++

    Installation des paquets :
# aptitude install aufs-modules aufs-tools


Cependant, comme j'utilise un kernel compilé par mes soins, je dois
installer et compiler "aufs-source" à la place du "aptitude install
aufs-modules" :
# module-assistant prepare aufs
# module-assistant install aufs

    Pour utiliser aufs, il est nécessaire de monter en premier les
partitions "physiques". Ici, elles seront montées dans /tmp/test/REAL/xx/ :


# mount /dev/sdb5 /tmp/test/REAL/05
# mount /dev/sdb6 /tmp/test/REAL/06

    Puis, il faut procéder à la "fusion" des deux partitions
/tmp/test/REAL/05/ et /tmp/test/REAL/06/ en les montant via "aufs" dans
/tmp/test/aufs/ :


# mount -t aufs -o dirs=/tmp/test/REAL/05:/tmp/test/REAL/06 none
/tmp/test/aufs/

    Le résultat est le suivant :
- On peut toujours écrire/supprimer des fichiers directement sur les
partitions /tmp/test/REAL/05/ et /tmp/test/REAL/06/, et ce, même après
le montage aufs. Les modifications apparaîtrons dans /tmp/test/aufs/


- Cependant, le principe de aufs est que SEUL l'un des points de montage
sera utilisé en écriture. L'autre point de montage sera UNIQUEMENT
utilisé en lecture. Cette approche est typique de ce qui est utilisé
pour les "live-cd" ou les "live-usb", ou le plus gros du "/" est sur un
CD ou une image de disque montée en loopback. La partie en écriture est
limitée à un seul support (ram, clé usb).

- Cela se voit lorsque l'on fait un "df"
# df
/dev/sdb5         1923052   1816396      8968 100% /tmp/test/REAL/05
/dev/sdb6         1923068   1014096    811284  56% /tmp/test/REAL/06
none              1923052   1816396      8968 100% /tmp/test/aufs


L'espace libre sur /tmp/test/aufs/ (8.968 ko) est en fait uniquement
l'espace libre de /tmp/test/REAL/05/ . Tout l'espace disponible sur
/tmp/test/REAL/06/ (811.284 ko) n'est pas vu... :=(

- Pour accéder à l'espace libre de /tmp/test/REAL/06/ , il faut démonter
le /tmp/aufs, et le remonter en inversant l'ordre des /tmp/test/REAL/05/
et /tmp/test/REAL/06/ :

# umount /tmp/test/aufs/
# mount -t aufs -o dirs=/tmp/test/REAL/06:/tmp/test/REAL/05 none
/tmp/test/aufs/
# df
/dev/sdb5         1923052   1816384      8980 100% /tmp/test/REAL/05
/dev/sdb6         1923068   1014108    811272  56% /tmp/test/REAL/06
none              1923068   1014108    811272  56% /tmp/test/aufs


Cette fois-ci, il y a plus d'espace libre sur /tmp/test/aufs/ (811.284
ko), car c'est celui de /tmp/test/REAL/06/.

- Dans la syntaxe du montage aufs, c'est en effet le 1er point de
montage qui est utilisé en écriture, alors que le 2nd est utilisé en
lecture. Normalement, on pourrait outrepasser cet ordre, en utilisant
les paramètres "=ro" et "=rw", comme par exemple :

# mount -t aufs -o dirs=/tmp/test/REAL/05=ro:/tmp/test/REAL/06=rw none
/tmp/test/aufs/

Mais chez moi, cela ne marche pas... :=(

- Démontage de tout ceci. Attention, il faut d'abord démonter le aufs
avant les montages physiques !!
# umount /tmp/test/aufs /tmp/test/REAL/05 /tmp/test/REAL/06




++++ FUnionFS http://funionfs.apiou.org/index.php?lng=fr ++++

    Le projet semble assez jeune, mais plus très actif.


    Installation à partir de paquets:
# aptitude install funionfs


    Pour ce test, j'utilise les partitions /tmp/test/REAL/07/ et
/tmp/test/REAL/08/, montées à partir des devices respectifs du /dev/sdbxx/


# mount /dev/sdb7 /tmp/test/REAL/07
# mount /dev/sdb8 /tmp/test/REAL/08

    Fusion des deux partitions :
# funionfs -o dirs=/tmp/test/REAL/08:/tmp/test/REAL/07 -o allow_other
none /tmp/test/funionfs/


Comparé à auth, c'est non pas le premier, mais la DERNIER point de
montage qui est par défaut utilisé en temps que zone d'écriture :

# df
/dev/sdb7         1923068   1014092    811288  56% /tmp/test/REAL/07
/dev/sdb8         1923068     35688   1789692   2% /tmp/test/REAL/08
funionfs          1923068   1014092    811288  56% /tmp/test/funionfs


Comme pour auth, seul un point de montage est utilisé pour l'écriture.
Ici, /tmp/test/REAL/07/. Il y a 811.288 ko de libre.

- Contrairement à aufs, les options "ro" et "rw" fonctionnent :

# umount /tmp/test/funionfs
# funionfs -o dirs=/tmp/test/REAL/08=rw:/tmp/test/REAL/07=ro -o
allow_other none /tmp/test/funionfs/
# df
/dev/sdb7         1923068   1014092    811288  56% /tmp/test/REAL/07
/dev/sdb8         1923068     35688   1789692   2% /tmp/test/REAL/08
funionfs          1923068     35688   1789692   2% /tmp/test/funionfs


Maintenant, il y a 1.789.692 ko de libre, car /tmp/test/REAL/08/ est vide

- A noter un bug : Ma première tentative d'écriture sur le funionfs
(/tmp/test/funionfs/olivier/), n'a pas marché. Il a fallut que je crée
un répertoire "olivier" dans le /tmp/test/REAL/07/, pour que celui-ci
apparaisse dans le /tmp/test/funionfs/. Les écritures suivantes dans le
/tmp/test/funionfs/olivier/ se sont passées sans problème.

- Démontage : Similaire à aufs : Le funionfs en PREMIER !!

# umount /tmp/test/funionfs
# umount /tmp/test/REAL/07 /tmp/test/REAL/08

- A noter que si "aufs" crée des répertoires cachés sur les points de
montage physique (utilisé pour des besoins internes: ".wh..wh.aufs" et
".wh..wh.plink"), ce n'est pas le cas de funionfs" :
# ls -la /tmp/test/REAL/05
drwxr-xr-x 5 root    root     4096 oct 11 17:47 .
drwxr-xr-x 8 root    root     4096 oct 11 17:30 ..
drwx------ 2 root    root    16384 oct 11 16:15 lost+found
drwxr-xr-x 2 olivier olivier  4096 oct 11 17:14 olivier
-r--r--r-- 1 root    root        0 oct 11 17:07 .wh..wh.aufs
drwx------ 2 root    root     4096 oct 11 17:07 .wh..wh.plink


# ls -la /tmp/test/REAL/07
drwxr-xr-x 4 root    root     4096 oct 11 18:30 .
drwxr-xr-x 8 root    root     4096 oct 11 17:30 ..
drwx------ 2 root    root    16384 oct 11 16:15 lost+found
drwxr-xr-x 2 olivier olivier  4096 oct 11 18:32 olivier



++++ UnionFsFuse http://podgorny.cz/moin/UnionFsFuse ++++

    Installation à partir de paquets:
# aptitude install unionfs-fuse


    Pour ce test, j'utilise les partitions /tmp/test/REAL/09/ et
/tmp/test/REAL/10/, montées à partir des devices respectifs du /dev/sdbxx


# mount /dev/sdb9 /tmp/test/REAL/09
# mount /dev/sdb10 /tmp/test/REAL/10

    Fusion des deux partitions, en utilisant la commande unionfs-fuse :


# unionfs-fuse -o allow_other /tmp/test/REAL/09=RW:/tmp/test/REAL/10=RW
/tmp/test/unionfs-fuse/

Notez l'utilisation des DEUX paramètres "=RW"...

Ce qui nous donne :

# df
/dev/sdb9     962504  17612   896000   2% /tmp/test/REAL/09
/dev/sdb10   1010888  17672   941864   2% /tmp/test/REAL/10
unionfs-fuse 1973392  35284  1837864   2% /tmp/test/unionfs-fuse


unionfs-fuse est le premier des 3 logiciels qui permet de monter les 2
partitions en monde écriture, et ainsi de fusion les deux espaces de
stockage libres !!!! : 896000 + 941864 = 1837864. Mais attention aux
résultats des tests... :=(

Notez aussi l'utilisation du paramètre "-o allow_other" qui permet à un
utilisateur non-root d'avoir un accès, ne serait-ce au moins qu'en
lecture, sur /tmp/test/unionfs-fuse/

- L'écriture sur le /tmp/test/unionfs-fuse/ se passe bien tant que la
première partition n'est pas pleine. Mais lorsque /tmp/test/REAL/09/ est
plein, il n'est plus possible de rajouter des fichiers. Alors que
/tmp/test/unionfs-fuse/ indique qu'il y a encore de la place (947516 ko)
!!! :=(

/dev/sdb9     962504  907960    5652 100% /tmp/test/REAL/09
/dev/sdb10   1010888   17672  941864   2% /tmp/test/REAL/10
unionfs-fuse 1973392  925632  947516  50% /tmp/test/unionfs-fuse


- Afin de bénéficier de la 2nd partie de l'espace de stockage, il est
nécessaire de démonter /tmp/test/unionfs-fuse/, pour le remonter en
inversant l'ordre de montages /tmp/test/REAL/09/ et /tmp/test/REAL/10/ :

# unionfs-fuse -o allow_other /tmp/test/REAL/10=RW:/tmp/test/REAL/09=RW
/tmp/test/unionfs-fuse/

- A partir de ce moment là, on peut continuer à remplir
/tmp/test/unionfs-fuse/ :

/dev/sdb9     962504   907960    5652 100% /tmp/test/REAL/09
/dev/sdb10   1010888   569016  390520  60% /tmp/test/REAL/10
unionfs-fuse 1973392  1476976  396172  79% /tmp/test/unionfs-fuse


- Démontage : Similaire au autres : Le unionfs-fuse en PREMIER !!

# umount /tmp/test/unionfs-fuse/ /tmp/test/REAL/09/ /tmp/test/REAL/10/




++++ Conclusion ++++

    j'ai testé les mécanismes de fusion de répertoires auth, funionfs et
unionfs-fuse.


    Ces 3 systèmes sont très bien adapter à la fusion de deux (ou plus)
arborescences de fichiers, afin de n'en monter qu'une seule. Ils
permettent tout les trois d'autoriser l'écriture des fichiers sur un
(unique) répertoire "réel".


    Mais aucun, n'est capable d'accéder à l'espace libre de tout les
supports. unionfs-fuse s'en sort un peu mieux que les autres (il affiche
l'espace complet disponible), mais ne permet pas d'y avoir accès
intégralement :=(


                            Olivier


-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
       /   / \  / \   \   Web:  http://olivieraj.free.fr/
      /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!