Bonjour,
Je souhaite expérimenter avec ZFS sur un serveur Debian à la maison (i.e usage domestique), en particulier pour des raisons de fiabilité/intégrité et de déduplication.
J'ai lu les avantages et les inconvénients par rapport à du LVM + Raid, mais je me pose encore quelques questions :
- stabilité de ZFS on linux (natif) avec Debian : est-ce que c'est mature ou bien vais-je beaucoup essuyer les plâtres ?
- impact sur la performance de la déduplication : je n'ai besoin de faire de la déduplication qu'au niveau d'un fichier et pour un disque dur de 1To environ. Afin que les performances ne soient pas trop dégradées, qu'est-ce qu'il faut que je prévois en terme de CPU et de RAM ?
De manière générale, est-ce que quelqu'un aurait un retour d'expérience ou des conseils à me donner avant de me lancer dans cette expérimentation ?
Merci d'avance !
# petit retour d'exp
Posté par briaeros007 . Évalué à 3.
alors zfs on linux est stable. Je l'ai utilisé pendant plusieurs année sans problème.
Par contre la dedup tue complètement les performances (et augmente x10 la quantité de RAM nécessaire. Tu peux ensuite mettre des trucs faire des trucs avec un SSD en plus, style mettre le L2ARC ou la ZIL dessus)
De plus pour un système ZFS la quantité de RAM disponible doit être importante.
Tu peux aussi essayer btrfs qui a comme avantage d'être déjà présent dans le noyau (et de pas se prendre la tête lors d'une montée de version), et qui possède à peu près toutes les qualité de zfs (mais n'est pas encore aussi stable, btrfs-rebalance me fait planter ma machine par exemple).
Perso j'ai migré mes disques vers btrfs car j'en ai marre à chaque nouveau noyau (je les fait à la main comme au bon vieux temps :) ) zfs ne fonctionne pas (soit parce que dkms a pas voulu bien compilé, soit parce que le noyau est trop récent).
Si tu ne comptes pas compiler toi même le dernier noyau à la mode, cela ne devrais pas poser trop de problème.
[^] # Re: petit retour d'exp
Posté par SaintGermain . Évalué à 2.
Très intéressant retour, merci !
Est-ce que configurer ZFS pour de la dédup au niveau du fichier ou au niveau du bloc change quelque chose au niveau des performances ou au niveau de la RAM nécessaire ?
Il me semble que cela doit être plus light pour de la dédup au niveau du fichier.
Je suis avec intérêt BTRFS mais il semble que ce ne soit pas assez stable à mon goûts et je souhaite avant tout la stabilité.
Je n'ai pas trouvé beaucoup de retour d'expérience récent avec ZFS et Debian stable (ou testing).
Les nouveaux noyaux ne sont pas si nombreux si on tourne avec Debian stable, donc effectivement peut-être que ZFS serait idéal dans ce cas là.
Merci encore !
[^] # Re: petit retour d'exp
Posté par briaeros007 . Évalué à 3.
de peu que je connais zfs, tu ne peux pas configurer sur quoi est fait le dedup : c'est forcément sur les blocs.
Mais ça a peut être évoluer depuis que j'ai commencé :).
Niveau perfs, il faut bien spécifier ashift=12 lorsque tu créé ton bloc (si tu as des gros disques)
Je te conseille de faire un test avec zfs avant de le mettre en prod car les perfs peuvent être assez décevante, surtout si le dedup est activé (en tout cas c'était mon cas).
Si tu as beaucoup de fichiers types texte ou identiques, active la compression sur le fs. Cela peut vraiment permettre de gagner en débit (ca peut couter largement moins cher de décompresser des données sur le CPU que de récupérer 2 fois plus de données du disque :) )
Il te faut aussi de préférence de la mémoire ECC, car il n'y a pas de fsck sur zfs et ce système de fichier n'apprécient que peut d'avoir un arbre corrompu (zfs ou fsck, les deux on la même galère, même si il parait que maintenant btrfs a un fsck opérationnel).
Sinon sur debian (ou ubuntu) aucun souci. J'utilisais les paquets ubuntu , mais comme de toute façons ils se compilent avec dkms et ton noyau en place tu t'en fiches si c'est ubuntu ou pas.
Sur la mailing list de zfs, il y a plein d'occurence avec debian, donc pas trop de soucis de représentativitée.
Concernant la stabilité de btrfs, ce sera sans doute la solution la plus pérennevu qu'elle est intégrée au noyau et donc continuera à être maintenu et déployée (et sur plusieurs archi).
Je crois que les readynas de netgear sont basée sur btrfs.
[^] # Re: petit retour d'exp
Posté par SaintGermain . Évalué à 2.
Je me suis trompé pour la dédup au niveau d'un fichier : ZFS marche seulement avec de la dédup au niveau du bloc.
J'hésite réellement entre ZFS et BTRFS, mais je pencherais plutôt vers ZFS qui a l'air beaucoup plus stable actuellement.
BTRFS est sans aucun doute l'avenir mais j'ai quelques doutes sur sa stabilité actuelle.
Est-ce que tu as un bon retour d'expérience sur BTRFS ?
Pour une utilisation de NAS perso (i.e. données pas super critique mais c'est pas drôle de perdre ses photos, pas besoin d'une super performance, par contre besoin de très très peu de maintenance au niveau administration système et mis à jour), tu penses que c'est sans problème ?
Vu le sujet ce serait limite intéressant de faire un journal sur ton retour d'expérience ? ;-)
Merci encore !
[^] # Re: petit retour d'exp
Posté par briaeros007 . Évalué à 3.
Sur btrfs je n'ai qu'un retour d'expérience relativement faible, je n'ai plus le temps de faire mumuse autant que je le voudrais (ahlala le travail et la veillesse).
au niveau stabilité pure, je pense que btrfs peut sans problème passer en prod.
Ensuite, comme je disais, sur btrfs il y a des trucs qui ne sont pas finis : le balance qui fait planter le noyau "ça le fait moyen" comme dirait certains .
mais les données restent saines et sauves.
lorsque tu créé ton arbre btrfs , tu peux spécifier le stockage des metadata et des data avec des algo différents (par exemple data en raid5 vs metadata en mirroring).
Puis pour les infos qui te sont vraiment importantes, il te faut une sauvegarde externe (et si possible hors site).
Bon je dis ça, mais bon j'ai bien une svg spécifique pour mon sys et mon /home, mais mon NAS je l'ai migré de zfs à btrfs depuis qq mois et pas de soucis niveau admin.
Pour un NAS perso, tu vas utiliser des quotas, mais pas certaines trucs spécifiques de zfs comme faire une cible iscsi ou équivalent. Donc je te dirais oui btrfs sans trop de soucis, par contre avec un raid5 minimum et mirroring complet des metadata (et si possible sauvegarde des données les plus importantes sur un disque hors de ce FS au mini).
Concernant le journal, j'ai déjà pas le temps de lire tous mes mails :'(
Mais sur zfs (au tout début on était encore en fuse) j'ai fait un journal
[^] # Re: petit retour d'exp
Posté par SaintGermain . Évalué à 2.
Ok je te fais confiance, je vais essayer de partir au début sur BTRFS et voir si cela tient la route.
Si je vois que c'est trop instable, machine arrière sur ZFS.
Mon objectif est vraiment la fiabilité en premier, mais par contre je ne peux me permettre que 2 disques durs de 1 To (c'est pourquoi je regarde un ZFS ou BTRFS plutôt qu'un ext4).
Si le rapport investissement/gain est vraiment intéressant, je peux éventuellement ajouter un petit SSD.
Donc je suis assez limité au niveau du RAID possible. Je vais me renseigner pour voir comment optimiser cela avec BTRFS.
Merci pour les infos. Si l'expérience se révèle intéressante je ferai peut-être un journal !
Bonne soirée
[^] # Re: petit retour d'exp
Posté par briaeros007 . Évalué à 3.
pour du mirroring btrfs semble plus indiqué.
Non pas parce qu'il est plus fiable, mais parce que tu pourras basculer plus facilement vers un raid 5 en rajoutant un disque de 1 To (ou plus)
Zfs ne permet pas d'importer un disque dans un vdev (on ne peut que remplacer un disque existant ou rajouter un spare).
btrfs permet le changement de paradigme (mirroring puis copie sur au moins 2 disques en rajoutant un disque).
Par contre, comme j'indiquais : le code de rebalancing n'est pas encore complètement au point (en tout cas sur mon noyal) donc il ne faut pas rajouter un disque actuellement (il va le prendre en compte et il va rajouter des données sans problème ni perte de donnée. Mais si tu fais des mirroring sur tes disques sont déjà plein avant de rajouter un disque, il va avoir un problème.car les données ne pourront pas être copiée sur au moins 2 disques , d'où le code de rebalancing).
Exemple chez moi de pool non rebalancé :
devid 3 size 1.82TB used 1.14TB path /dev/sd?
devid 4 size 1.82TB used 236.03GB path /dev/sd?
devid 1 size 1.82TB used 1.14TB path /dev/sd?
devid 2 size 1.82TB used 1.14TB path /dev/sd?
Donc sur le disque rajouté (devid 4, j'étais déjà en raid5 avant) il n'a mis que 236 Go (bon j'ai rien rajouté depuis donc il n'est pas du tout bloqué )
Ensuite si tu es riche et que tu fais tes upgrade en rajoutant d'un coup 3 disques de 2/3/4 To libre a toi.
Que ce soit zfs ou btrfs, tous aiment bien avoir des disques de tailles identiques dans leur pools. (tu peux avoir plusieurs pools. Sous zfs c'est sur, sous btrfs aussi quasi sur).
Bon ensuite si tu veux un truc vraiment ultra fiable (mais là je peaufine)
-> alim de qualité!!! (honnêtement j'ai perdu 2 disques à cause d'une alim. Quand ils font du 24/7, ça vaut le coup d'investir un peu plus.)
-> RAM ECC (même chose avec le 24/7. Par contre c'est souvent 2x plus cher, et il faut une carte mère qui le supporte).
-> disque de série et/ou de fabricant différent (pour éviter la défaillance qui touche une série particulière et que tous tes disques tombent d'un coup).
-> raid6 (2 disques en moins et ca continue de rouler), ou tout en raid0+1 (je confond toujours raid 10 et raid 01)
--> si tu es très riche : Zserie avec opération en double et vérification de la cohérence du résultat XD
Dans tous les cas, pas de striping /o\
bonne soirée à toi aussi.
[^] # Re: petit retour d'exp
Posté par SaintGermain . Évalué à 2.
Mais c'est une mine d'or tes posts ! ;-)
Le coup de l'alim de qualité je n'y avais même pas pensé (tu as des références à conseiller ?).
Pour les disques différents, je ne suis pas sûr : cela complique (un peu) l'administration (déjà que je me bats régulièrement avec mes WD sur le parquage des têtes) pour un gain relativement minime (je ne me souviens pas avoir entendu parler de disques qui claquent en même temps). Si une série est défectueuse, on a normalement le temps de changer le disque.
Pour l'extension possible avec des disques supplémentaires, en pratique ce sera impossible pour moi (pas de place physique dans le NAS perso). Donc il faut tout prévoir dès le début et ce sera je pense 2 disques dur (je suis pas sûr qu'ajouter un SSD soit très rentable pour du BTRFS, comme le coup du ZIL/L2ARC avec ZFS).
Franchement cela aurait valu un journal : je pense que d'autres auraient été bien intéressés.
Merci beaucoup !
[^] # Re: petit retour d'exp
Posté par briaeros007 . Évalué à 3.
demande aux entreprises, tu verras que si ^
Dans une de mes anciennes boites ont a eu le cas: 2 disques qui sont tombés en même temps (a une semaine d'intervalle) dans le même pool (raid matériel).
Heureusement c'était sur du raid6, car on a pas eu le temps de réceptionner le remplacement du premier que le deuxième tombe.
Vu le prix d'un SSD, il est bien plus intéressant de prendre des disques plus gros, surtout pour un nas perso.
Pour un NAS qui n'a que deux emplacement … changer de nas ? :P
Si tu est vraiment bloqué sur le nombre d'emplacement, zfs comme btrfs pourront prendre la taille max disponible en appliquant un resilvering en deux étapes
2*1 To --> tu échange un disque de 1 To avec un disque de 4 To (par exemple).
--> tu resilverise (cad qu'il copie toutes les donnes afin que le raid devienne cohérent).
une fois que c'est ok, tu fais la même chose avec l'autre disque.
Et oh tu vas passer d'un pool de 1 To en mirroring à un pool de 4 To en mirroring (et deux disques de 1 To qui ne te servent plus pour ton NAS)
ça ça fonctionne pour zfs comme pour btrfs :)
Ps : merci pour toutes tes appréciations, c'est toujours plus agréables de discuter avec des gens comme toi :)
[^] # Re: petit retour d'exp
Posté par SaintGermain . Évalué à 2.
Pour le coup des disques durs qui flanchent simultanément, c'est exactement ce que je voulais dire : pour un NAS perso quand tu as un disque qui lâche tu peux te permettre de tout arrêter et d'attendre sagement le nouveau disque dur.
Dans une entreprise, j'imagine que tu ne peux pas demander aux employés de ranger leur bureau en attendant… ;-)
Au niveau emplacement, j'ai deux emplacements 2.5" et je peux éventuellement rajouter un petit SSD (format mSata ou un truc du genre) si je serre bien tout. Il faut que je voie si avec BTRFS c'est vraiment avantageux (pour ZFS j'ai lu le coup du ZIL et de L2ARC).
Je pense que cela va être intéressant pour moi de découvrir un nouveau FS.
Merci !
# petit retour d'expérience en ZFS
Posté par mtiburs . Évalué à 3.
Bonjour,
Je viens de tomber sur ce post en cherchant des trucs sur ZFS.
Je viens de voir quelques échanges et je me dis que je pourrais y ajouter un petit grain de sel ;-)
Je n'étais pas inscris sur LinuxFR … c'est chose faite.
Voici ce que je peux dire:
J'ai testé ZFS sur Freenas puis sur Nas4Free (pour info, Nas4free est la suite de Freenas, Freenas ayant été racheté par une société commerciale à la version 8)
Cela fait des années que j'utilise ZFS, mon serveur perso de la maison a 3 disques de 2To sur une petite carte D510 Intel avec 4Go de RAM, ça marche Nickel et ça fait serveur DLNA.
J'ai 3 onduleurs … sans batteries, lol … et mes nas sous ZFS ont connus plusieurs fois des coupures de courant en plein travail (écritures multiples) … même pas d'erreurs ! normal c'est du COW (CopyOnWrite).
Cela fait quelques mois que je me mets a utiliser ZFS sur Linux et je trouve que cela marche très bien, très simple avec des disques usb avec la notion d'export (pas besoin de partoche, ça dit ce qu'on peut monter .. ou pas avec la commande zpool import).
Pour la gestion de ZFS, il faut de la RAM, c'est mieux mais pas obligatoire, avant, cela posait des pb, mais depuis quelques temps la gestion est mieux faite, normalement, on dit qu'il faut 1Go de RAM par To.
En fait ce qu'il faut comprendre c'est que ZFS va fonctionner par couches, il utilise d'abord la RAM, puis le(s) SSD; puis le(s) disques.
Pour ma part, j'ai commencé avec du SATA, mais aujourd'hui j'utilise du SAS, pas pour les donnée mais pour le log (des fois) mais surtout pour le cache (zpool add nomdupool cache /dev/sdd /dev/sdd, par exemple)
Quand on a pas de RAM et pas de SSD, il faut avoir un bon cache disque, je conseille de trouver de cartes SAS (de 20 à 100 euros sur les sites de bonnes affaires et de mettre quelques disques SAS (mais on peut utiliser un disques SATA ça marche aussi … mais moins bien;-)
Perso, je monte à plus de 1,1 Go/s avec 6 disques Seagate de 300Go 15k7, mais déjà avec 2 disques en raid0 matériel ou en entrelacés ZFS, on peut avoir de bons résultats.
La carte SAS, à l'avantage de passer par le "pont-nord" de la carte mère, alors que les ports SATA passeront par le "pont-sud", ce qui dans certains cas donneront des performances mauvaises (le SATA peut être bon sur le papier mais ça ne tient pas la route "en charge", il a un fonctionnement plus simpliste que le SAS)
Une astuce, on peut mettre du SATA sur une carte SAS et bénéficier du "pont-nord" (accès direct avec le proc)
Si je peux donner un conseil, c'est de privilégier ce point: avoir un "bon cache ZFS" (Si possible SSD ou SAS: ne pas oublier que ZFS a été conçu pour du SAS).
Pour la déduplication, je viens de faire pleins de tests là dessus, en fait, vouloir dédupliquer toutes ces données est une utopie, car cela va représenter une table de déduplication immense et il faudra une machine de guerre pour gérer cela.
Pour ma part, j'utilise désormais la déduplication ZFS sous Debian uniquement sur des fichiers VMDK de machines virtuelles et de même type. J'ai 150Go à sauvegarder par jour.
Tous les essais de déduplication que j'ai fais sur:
- l'ensemble de mes données (fichiers courant)
- les fichiers OVA
- la vidéo
s'est révélés catastrophique, car quand la table augmente, le temps d'accès devient très long et le taux de transfert peut finir en Ko/s !!!
En revanche, si on cible "ses données", c'est à dire que l'on comprend bien ce qu'on veut dédupliquer, on a un bon résultat, par exemple, sur un fichier brut de type VMDK, il y aura quelques Mo de différents. Ce fichier (brut) ne bougera pas et c'est seulement les différences qui seront écrites en plus par ZFS. Si on copie un fichier OVA, soit une exportation d'un fichier VMDK+config, alors là on aura une différence depuis le début et, du coup, c'est tous les blocs qui seront différents … adieu la déduplication !)
On peut jouer sur le cache primaire et secondaire pour améliorer mais ça ne fera pas tout.
Après quelques copies de fichiers VMDK, j'ai un cache de 3Go, donc, pour que le système puisse s'en sortir, deux solutions:
- soit du SSD et là, il trouve rapidement "ses petits" (vu le prix des SSD j'abandonne)
- soit "l'ensemble disque" est performant et là on aura des performances acceptables (actuellement, j'ai 2 disques de cache 15k7 (200Mo/s pour chaque disque) et une carte LSI avec 512Mo de cache).
J'ai ciblé mes sauvegardes de fichiers vmdk en faisant un pool dédié (de même type) et je ne fais que ça, j'arrête surtout ZFS quand je change de pool (/etc/init.d/zfs-fuse stop), car sinon, il va garder sa table en mémoire et elle augmentera avec les autres données et là ce sera 10Go en cache qu'il faudra scruter !
Donc, le ZFS oui ! la déduplication … oui MAIS sous des conditions strictes de bon sens avec une bonne compréhension des données que l'on possède… ou alors on investi dans une carte bi-xéon avec 192Go de RAM, 32Go de SSD, et là c'est fantastique.
Pour info, pour avoir une bonne déduplication, il faudrait "aller" vers des blocs petits (512 octets), la déduplication par défaut est sur des blocs de 128Ko (plus les blocs sont gros, moins ça déduplique).
Avec des fichiers de type "image de disque", vdi, ou vmdk, il faut utiliser les blocs de 128Ko.
Pour l'instant, je suis en production avec une B75/AsRock/8Go de RAM avec un i5-2500, carte LSI de 512Mo de cache et 4 disques SAS 15k7, ça rame en moyenne à 15Mo/s, c'est le temps qu'il faut pour scruter le cache et la table.
Je suis pris à la gorge car mes données s'accumulent, mais bon, ça charge doucement, le facteur de déduplicaction monte, c'est l’essentiel !
Mais dans quelques temps, je mets en service une carte bi-xéon avec 32Go de RAM avec 4 ou 6 disques de cache soit 10 disques durs SAS uniquement pour le fonctionnement de ZFS (2 cartes contrôleurs SAS), tant que je peux le faire en 'disques durs', je ferai ! na!
..; en été c'est pas top avec 10 disques ;-/ .. quand les SSD seront moins cher j'investirai.
Voilà en gros mon avis.
PS: je crois que les nouvelles cartes mères n'ont plus de "pont-nord".
[^] # Re: petit retour d'expérience en ZFS
Posté par mtiburs . Évalué à 2.
petit rectificatif: 1,1Go/s c'est en ext3 avec mdadm … pas sous ZFS (le système de gestion transactionnel des données est plus complexe et les performances ne sont pas équivalente, c'est le prix a payer pour l'ultra-fiabilité de ZFS)
[^] # Re: petit retour d'expérience en ZFS
Posté par mtiburs . Évalué à 1.
rectificatif, j'ai donné 15Mo/s, mais j'ai désormais plus de 25Mo/s de moyenne avec un facteur de déduplication de 3 et un cache de 10Go pour le cache ZFS (cache primaire et secondaire en "metadata")
Mes disques en cache ne font pas trop de bruit par contre, sans cache sur le contrôleur SAS, le bruit devient "agricolesque".
[^] # Re: petit retour d'expérience en ZFS
Posté par SaintGermain . Évalué à 2.
Salut !
Merci pour ton avis, c'est sympa.
Et bienvenue ! Tu verras que l'ambiance est sympa sur ce site. On y trouve pleins de bonnes infos même si parfois les discussions partent dans tous les sens.
Pour la déduplication à des fins de sauvegarde, j'ai écris une dépêche sur le sujet il y a un moment, peut-être que cela t'intéressera :
http://linuxfr.org/news/r-evolutions-dans-le-monde-de-la-sauvegarde-de-donnees
Je ne peux donc pas me permettre financièrement trop de folies au niveau architecture. En particulier ce sera 2 disques durs maxi et éventuellement un SSD.
De plus il faut que la maintenance soit proche de zéro, en particulier lors des mises à jour du système et du noyau.
Il semblerait que ce soit un peu difficile de bien gérer la performance lorsque l'on active la déduplication donc je vais abandonner l'idée pour le moment.
Au niveau fiabilité, il semblerait que ZFS soit mieux (merci pour ton retour d'expérience). Au niveau maintenance, il semblerait que ce soit plus facile avec BTRFS. Mon coeur balance donc.
A noter que j'ai lu que BTRFS a inclus récemment une déduplication différée ou manuelle. Je vais creuser la question.
Si tu veux faire un journal sur le sujet, je pense qu'il sera très bien accueilli et tu auras potentiellement des commentaires intéressants sur ton architecture !
[^] # Re: petit retour d'expérience en ZFS
Posté par briaeros007 . Évalué à 3.
pour le dedup de btrfs (de même que la defrag*) il y a des outils offline (cad pas en même temps que les io). Le dedup online est en cours.
Par contre ils ne sont pas forcément présent d'office (en tout cas bedup sous debian non) sur les distribs.
Perso c'est une grande attente le dedup offline, car ça permet d'éviter un impact en perfs important, et de le programmer lorsqu'il y a peu d'activité (après les sauvegardes et avant les utilisateurs :) )
: * : bon la defrag se fait fichier par fichier … ensuite tu fais un script pour voir quels sont ceux qui sont bien fragmenté (si ça arrive) et appliquer la commande automatiquement, par exemple après ton dedup qui se fait après ta sauvegarde (la nuit vas être longue XD)
[^] # Re: petit retour d'expérience en ZFS
Posté par SaintGermain . Évalué à 2.
Oui une dédup offline c'est vraiment intéressant pour un NAS perso (il va falloir que je prenne des disques durs silencieux…).
Je vais attendre sagement que cela arrive sur Debian alors…
Merci
[^] # Re: petit retour d'expérience en ZFS
Posté par mtiburs . Évalué à 3.
Salut,
Merci pour le lien, c'est très intéressant.
Avant toute chose, une question bête: comment fait-on pour être informé des nouveaux messages sur le forum ? je pensais que j'allais recevoir un courriel lorsque le fil de discussion allait "vivre" mais apparemment, ce n'est pas le cas.
Pour ZFS, j'ai investi (pour voir, lol … ouille ça coute cher quand même !) dans un SSD de 500Go (tant qu'à faire), j'ai regardé la différence avec mes disques SAS et pour l'instant sur des petites taille de cache, je ne vois pas trop la différence.
Perso, je trouve ZFS très facile d'utilisation, si on a un disque /dev/sda, on fait: zpool create mypool /dev/sda
puis, un zfs set dedup=on mypool et c'est tout !
quelques zpool list pour voir la dedup de temps en temps.
Si on a que des disques sata, on peut les mettre en raid0 avec mdadm ça accumule les performances pour pas cher:
zpool add mypool cache /dev/md0
mais on peut aussi utiliser séparément les disques avec ZFS:
zpool add mypool cache /dev/sda /dev/sdb /dev/sdc
avec zpool iostat -v 1, on voit le travail du cache
Je trouve que ZFS offre pas mal de possibilité sur Linux, soit en dev directement, soit en iscsi, soit en fichier … ou pourquoi pas tous les 3 en mirroir ZFS ;-)
En tout cas je reste ouvert sur une déduplication en "offline", car en fait, j'utilise ZFS qui est "online" dans un mode plutôt "offline", d'un certain coté çà à l'avantage de faire les deux.
J'ai regardé du coté de bup, mais j'ai rien compris ;-/
vous pouvez essayer la déduplication ZFS facilement pour voir
zpool create mypool /dev/sdb
et vous voilà avec un pool de la totalité du disque
un p'tit coup de zfs set dedup=on mypool et c'est partit pour la dedup
vous copiez une image iso de CD dedans, puis la même avec un nom différent, un petit zpool list, et normalement vous avez une dedup égale à 2
là, il faudra voir la vitesse d'écriture, et, voir si ça "tient la route" ou pas, c’est votre matériel qui fera les choses.
pour améliorer:
mettre un disque en plus (zpool export mypool, arrêt de la machine et ajout du disque, zpool import mypool)
zpool add mypool cache /dev/sdc
puis,
zfs primarycache=metadata mypool
zfs secondarycache=metadata mypool
Je mets toujours les deux cache en metadata pour minimiser la RAM et pour ne pas écrire un cache trop gros, car celui-ci augmente énormément et le temps de lecture augmentera par la même occasion.
regardez avec zpool iostat -v 1 le travail du cache lorsque l'on recopie le même fichier
si on peut, on rajoute un second disque:
zpool add mypool cache /dev/sdd
l'avantage avec ZFS, c'est qu'on peut facilement récupérer ses disques "à chaud", par exemple, si on a un cache de 2 disques dont /dev/sdc, on fait:
zpool remove mypool /dev/sdc et sdc est dispo de suite, et tout cela pendant que "ça tourne".
On peut imaginer démarrer un pool sur un fichier, le mettre en mirroir en iscsi et ensuite détacher le fichier, ainsi, on peut déplacer un pool en production, on peut jouer avec des To "en plein boulot", après, faut que le matos le permette, avec un PC normal en Go ça va ;-) … en To c'est une une autre histoire !
Toutefois, Btrfs est sans doute intéressant et je suivrai de près cet outil, mais pour l'instant j'ai besoin de quelque chose qui marche tout de suite, ZFS est disponible et fonctionne très bien sous Linux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.