[Linux-bruxelles] mdadm vs LVM (suite)

[Jean-Marc]

Tue, 28 May 2019 17:48:06 +0200
"Depuydt, Patrick" <patrick at htag2.com> écrivait :

> Bon, on vis dans un monde libre et loin de moi l'idée de te dissuader de
> faire ça avec LVM tout seul. Mais comme je l'ai déjà répété, ce n'est pas
> la meilleure méthode.

Merci pour l'avertissement.

> Ne te renseigne pas seulement sur comment le faire, renseigne toi aussi sur
> comment réparer en cas de problème et tu verra que lvm tout seul c'est
> moins chouette à réparer que quand y'a du raid derrière.

C'est en cours.

> Bref, pour être vraiment honnête, dans ton cas je pense que btrfs est une
> meilleure solution.

Là, par contre, les systèmes qui offrent/mélangent FS et gestion de volumes physique, c'est bof-bof.

En théorie, c'est vraiment bien.  Je me souviens de ZFS et des ses multiples possib' (gestion RAID, snapshots, compression on-the-fly, gestion de quotas plutôt que taille fixe et j'en passe).

Par contre, quand ça plante, on sort le backup, point-barre.

Et côté perf', c'est plutôt moche.

Je viens de revoir un des derniers benchmarks sur phoronix [0] et BTRFS reste loin derrière EXT4/XFS.

Dernier point concernant BTRFS, la doc sur le wiki de Arch [1] commence avec un joli avertissement sur certaines "features" annoncées comme instables.  C'est pas vraiment engageant.

Bref, sans être un spécialiste de ce genre de système, je ne les trouve pas sexy.

Mais merci pour la réponse et le conseil, en tous les cas.

Je vais néanmoins essayer de voir ce que donne les outils de gestion LVM.
J'ai bien deux vieux disques pour tester un débranchement à chaud et voir comment ce comporte le RAID de LVM.

> ++

Jean-Marc <jean-marc at 6jf.be>
https://6jf.be/keys/ED863AD1.txt

[0] https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num=1
[1] https://wiki.archlinux.org/index.php/Btrfs
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 833 octets
Desc: non disponible
URL: </pipermail/linux-bruxelles/attachments/20190528/9aa6808d/attachment-0002.sig>