[Linux-bruxelles] mdadm vs LVM

[Depuydt, Patrick]

Y'a pas photo les mecs, ce n'est pas la même chose!

RAID c'est pour aggreger les disques, donc dès que tu as deux disques tu
est potentiellement intéressé par mdadm.

Après LVM c'est pour gérer tes volumes de manière plus souple que des
partitions.

Et donc en général on à une couche RAID puis une couche LVM; après avec tes
disques logiques tu fait ce que tu veux...

Mais en tout cas bon, y'a pas a hésiter c'est les deux que tu veux utiliser.

Pat.
Contactez-moi pour plus d'infos.


On Sat, Mar 9, 2019 at 11:08 AM Serge Smeesters via Linux-bruxelles <
linux-bruxelles at lists.bxlug.be> wrote:

> Salut Jean-Marc,
>
>
> Selon moi, le RAID doit être 6, avec minimum 3 ou 4 disques et donc la
> possibilité d'en perdre 2. Un disque de rechange (“spare” en anglais)
> devrait également être présent pour automatiquement prendre le relais du
> premier disque qui deviendrait défectueux. Ça nous fait donc entre 4 et
> 6 disque minimum, pour un espace équivalent à 2. Ha oui, car j'oubliais
> qu'idéalement les disque doivent être de même capacité.
>
> Alors, partant de là, j'ai fais l'expérience de disques de capacités
> différentes. Au départ, des 1, des 2, des 3 To. J'ai donc décidé de
> faire un  RAID sur autant de partitions de 1 To. Pour les restes, ça
> devenait des espaces de stockage sans la sécurité du RAID. C'est donc
> possible, ça tourne toujours en ce moment-même. Depuis lors, j'ai été
> amené à remplacer des disques, de 1 vers 2 ou de 2 vers 3 To, ou encore
> un disque défaillant. Cela c'est toujours bien passé :)
>
> J'utilise le RAID logiciel (“software” en anglais) du noyau Linux (pour
> le coup), et donc l'utilitaire mdadm.
>
> LVM, j'ai jamais utilisé. Je préfère l'approche "plus empirique" de
> l'unionfs au niveau fichiers. En effet, de ce que j'ai compris, le LVM,
> c'est surtout pour concaténer les bloques de différents "disques" en
> dessous d'un système de fichier. Je sais pas bien comment ça se passe
> avec une partie RAID et une partie "non-RAID"... Comment savoir si un
> fichier se trouve sur des bloques qui se trouve sur du RAID ? Et si tout
> le LVM est sur du RAID, à quoi ça sert ? Ou alors plusieurs RAID ? :/
>
> Bref, avec un unionfs, il y a les deux approches :
> - D'un côté je place les fichiers sur différents "disques", RAID ou pas.
> - De l'autre j'ai une vue unifiée.
>
> Agrandir l'espace "non-RAID" est facile, juste ajouter un élément au
> montage unionfs, "remount" et c'est fait.
>
> Agrandir le RAID, c'est plus délicat. Mais je pense que c'est pareil
> avec LVM à ce niveau là. Il y a toujours le "grow" sur le fs qui est
> délicat.
>
>
> Maintenant, si tu as du *disque* et du SSD, l'idéal serait que le SSD
> puisse être utilisé de manière transparente pour accélérer les accès aux
> fichiers les plus utilisé. Je sais pas si ça existe. :/
>
> Par contre, je sais qu'il est possible d'orienter d'avantage d'accès
> vers un composante d'un RAID, pour les lectures.... Pour "user" un
> disque légèrement plus que les autres, et donc pouvoir "prédire" le
> disque à remplacer "prochainement"...
>
> Plein de choses possibles en sommes :)
>
> Bon amusement :)
>
> À+,
> Serge Smeesters
> http://www.gnucomputer.be/
> http://www.spaceeman.be/
>
>
> Le 9/03/19 à 10:03, Jean-Marc a écrit :
> > salut la liste,
> > J'ai deux disques dans mon PC que je compte utilisés en plus du SSD sur
> lequel j'ai mon système.
> >
> > Je pense les regrouper en RAID, histoire de me protéger de certaines
> pannes.
> >
> > Entre mdadm et LVM, j'hésite.
> >
> > LVM me semble plus souple (RAID au niveau volume logique si j'ai bien lu
> la doc).
> >
> > Des conseils ?  D'autres suggestions ?
> >
> > Merci d'avance.
> > Jean-Mar
> _______________________________________________
> Linux-bruxelles :
> Èchanger, partager, s'informer par mails sur toute action, proposition
> accordée avec: http://www.bxlug.be/?Nos-statuts
>
> Linux-bruxelles at lists.bxlug.be
> https://listes.domainepublic.net/listinfo/linux-bruxelles
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/linux-bruxelles/attachments/20190311/2b0d7ff4/attachment-0002.html>