Reprise du message précédent :

Dit comme ça, on dirait un bug.
Faut ptet remonter et/ou voir si ça a déjà été rapporté.

Tu parles de la partie avec le daemon zed ?
 
Si oui, il semble y avoir un "bug" deja en cours si je me me fit au retour que j'ai eu sur github:
 
https://github.com/zfsonlinux/zfs/issues/5553

Bonjour à vous,
 
Petite question:
J'ai un Raidz2 de 4*1To, donc 2To utilisable et j'ai un soucis d'utilisation par les zvol.

 
Donc 1.1To d'utilisation mais en faite que 95Go.
 
j'ai supprimé 2 zvol en faisant zfs destroy tank/vm-205-disk-1 pareil pour le disk-2 qui lui faisait 1To.
 
mais j'ai pas l'impression qu'il ai libéré l'espace.
 
une idée de pk et de comment résoudre ca?
 
Merci
 

Tu es sûr que tu n'as pas des données stockées à la racine de ton pool (sous /tank ou le point de montage utilisé) ? Parce que c'est ce qu'indique la première ligne : USEDDS remonte l'espace occupé sur le volume, et USEDCHILD celui des sous-volumes.

j'avais un point de montage mais supprimer depuis

edit: j'ai remonté le point de montage et même si je vois pas le fichier un rm du dossier en question prend vachement de temps donc mon gros fichier est dedans

merci pour la piste

Bonjour à vous,
 
Je reviens avec une petite question:
J'ai toujours mon disque d'1T sur une VM et quand je vérifie sa taille pas de soucis il fait 1T.
 
sauf que quand je fais un zfs list, il fait 1.48T oO
 
une idée de comment vérifier et comprendre pk j'ai 480G de différence?
 
Merci

 
Est-ce que tu aurais augmenté la taille du LUN ?
J'ai souvent ce type de soucis. En gros un Lun de 1 To que j'augmente à 1,5 To prend parfois 2,5 To

Nop pas fais ca, la seule solution que j'ai trouvé:
 
détruire le disque et le recréer

Bonjour,
 
Petite question: j'ai un Raidz2 de 4*1To et je songe à y rajouter un autre Raidz2. on est d'accord que je me retrouverais avec 4To et que les données seront réparties sur les deux Raidz2?
 
Merci

De mon faible niveau de connaissance je suis tenté de dire que oui les données seront répartie entre tes deux raidz2.
Il me semble savoir que ZFS va privilégier le moins remplis pour les écritures mais je n'en suis pas sûr.
Pas plus que je ne sais pas comment la répartition d'un fichier peut se faire (sur les deux raidz2 à la foi comme un raid0 ou sur un seul ou en fonction du débit d'écriture ?)

mefiez vous des cumuls des raids sur les meme grappes  
dans certaines circonstances c est totalement contre-productif voir instable et generant des pertes de donnees  
 
neamoins j ai pas teste avec les versions plus recentes de raidz /zfs

hum intéressant ca, je vais me renseigner du coup, merci

zfs on linux 0.7.0 est sorti avec plein de nouvelle features: https://github.com/zfsonlinux/zfs/r [...] /zfs-0.7.0
 
vu que c'est une release majeure je conseille d'éviter cette version en production sans passer au préalable par une batterie de tests poussée...

Hello,
 
la dernière version sur les backport est bien la  0.6.5.9-2~bpo8+1 ?

en backport-jessie oui
 
en backport-stretch c'est 0.6.5.11-1~bpo9+1

sinon tu as les backports "jessie-sloppy" en 0.6.5.11-1~bpo8+1
 
https://backports.debian.org/change [...] loppy.html
 

Yes c'est exactement ce que je viens de voir, merci
 
J'ai pas encore migré vers Stretch, je suis en train de m'en occuper.
 
Certain ont migré de la 0.6.5.X vers la 0.7.X ? Obligé de le faire manuellement ?

Je déconseille les 0.7.x pour le moment.
Ca devrait être OK pour la fin de l'année.

https://www.theregister.co.uk/2017/ [...] nto_linux/

On s'en fout un peu, je doute que le LLNL se laisse bouffer la gueule par Oracle qui souhaite reprendre la main sur OpenZFS. De toutes façons, le fork par rapport a Oracle ZFS sur les fonctionnalités est trop important : je doute qu'ils fassent du dev pour rendre compatible les ZPool Solaris en 38/39 avec ceux en 28/5000 d'OpenZFS.
 
OpenZFS ne sont que des specs, et pas une implémentation, l'implémentation d'OpenZFS sur Linux est ZFSonlinux qui est GNUGPLV2. ZFS BSD est en GNUGPL également et MacZFS est closed mais suis les spec OpenZFS.
Pour moi, c'est juste du flan, Oracle en mal de reconnaissance. (et theregister qui sont dans les choux sur les informations autour de ZFS).

o/
pour ma part, j'ai 2 machines persos sous debian + zfs on linux (v0.6.5.7-8-jessie pour l'instant)
4 disques de 4To en 2xraid1, + un ssd en slog. très satisfait de l'ensemble et des perfs
ils se répliquent entre eux chaque nuit avec ZincrSend (https://github.com/bahamas10/zincrsend) qui marche très bien
pis le bonheur des snapshots   (ce qui m'a sauvé la vie 2 fois pour l'instant )
Hâte de voir les nouvelles features !
Sinon quelqu'un sait ou ca en est le chiffrement natif sur ZoL ? c'est vraiment le seul truc qui me manque.
 

je me tâte aussi, à migrer mes 2 jessie en stretch. en dehors de zfs (et fucking systemd que jai désactivé) ça devrait bien se passer
 

Attends les 1ers retours, malheureux !  

Bon, j'ai testé dans une VM l'upgrade d'une debian 8 vers 9...
Le systeme est OK mais zfs est tout cassé  
(pas mal de probleme de dépendances pendant l'upgrade, notamment libzfs2, libuutil1 qui devient libuutil1linux, zfsutils et quelques autres..)
pour régler, ces dependances, désinstaller completement ZFS et le réinstaller (apt install zfs-dkms)
ca vient ptêt aussi du fait que sous jessie on téléchargeait/installait un paquet debian-zfs, et sous stretch, on installe directement zfs-dkms, et que les 2 sont pas trop compatibles ?
Bref, je recommanderai, avant d'upgrade debian, d'arreter et desinstaller completement zfs (export pool, stop service, modprobe -r zfs et apt-get remove --purge zfs*) puis upgrade debian puis reinstaller zfs-dkms.

Et une fois upgradé/rebooté sous stretch, les services zfs (check,mount,share...) sont prévus pour systemd, mais n'existent tout simplement plus pour sysvinit  
Et comme depuis jessie j'éradique systemd, ben au démarrage, le pool n'est pas vérifié/importé/monté automatiquement.
solution manuelle: zpool import tank
Par contre, en reinstallant systemd, tout se lance bien..
ça craint vraiment si on arrive à un moment ou les machins systemd sont prioritaires, et ceux sous sysvinit commencent à disparaitre    

up
pour info, les dernieres versions du paquet zfutils-linux n'integrent plus les scripts d'init pour sysvinit
normalement y'en a 4 installés dans /etc/init.d/

Une fois récupérés dans l'ancien paquet, il faut les mettre dans /etc/init.d
puis un coup de

(et pareil pour les 3 autres)
et c'est bon
Cela vaut aussi bien pour stretch (dans le dépot "contrib" que pour jessie dans les backports)
y'a un bug debian à ce sujet
https://bugs.debian.org/cgi-bin/bug [...] bug=826994

Bonjour,
 
Au cas où un d'entre vous aurait mis du ZFS en réplication via GlusterFS, je suis preneur !  
=> http://forum.hardware.fr/hfr/OSAlt [...] 6006_1.htm

ZFS est mnt proposé sur le repo backport.
 
Du monde a tenté la migration de la 0.6.x vers la 0.7.x ?
 
edit: migration OK sans soucis

est-ce que quelqu'un sait si la branche 0.7 est considérée stable maintenant ? (on en est quand même à la 0.7.5)

La 0.7.5 est stable oui. (assez pour plus de 21 jours sans publier une nouvelle version)

http://www.jonkensy.com/intel-micr [...] ss-in-zfs/

 
C'est léger comme article. Pas d'analyse, et le test est fait dans une VM (et on sait que les patchs affectent potentiellement la virtualisation plus que le reste).

 
Ben en même temps, c'est un cas d'usage pour 80% des install ZFS existantes. Mais oui, il constate plus les pertes d'IO liées au fait que ZFS soit dans une VM (hmmm miam le cas a 30% de pertes) alors que sur bare metal tu te tape grand max 5%, surtout si t'as des bonnes cartes hôtes avec DMA (et donc des bons drivers) parce que ZFS est quasi full user space (il ne l'est plus quand il doit accéder au matos quand il est monté dans une VM). Pour les 20% restants, comme précisé on est en dessous des 5% de pertes. Cas typique de nodes ZFS sur bare metal dans un clust ceph ou plus directement en LUSTRE.
 
Le vrai bottleneck sur le stockage haute performance ne va pas se situer sur ZFS dont les perfs devraient se maintenir, mais sur les MDT (qui eux utilisent un max de stockage ram/SSD et des accès en mode kernel). Les OSD et ZFS restent, hors matos spécifique (node full SSD monté dans une VM) dépendant de la vitesse max des disques durs (le temps de compute et les accès kernels sont limités de facto). Reste le cas particulier du raid 6.

 
J'ai pas compris ce qui était en gras.

sous linux lustre est userspace (module fuse, aka Filesystem in Userspace), par contre zfs c'est un module kernel lui

ok

 
C'est un module kernel mais c'est pas pour autant qu'il est "kernel space"

 
ZFS tourne dans l'espace noyau, "kernel space". Sauf si tu le fais tourner dans FUSE mais il me semble qu'il n'y a plus aucune implémentation qui fait ça sérieusement.

Les périphériques de bas niveau sont des modules user space. Des interfaces pour l'utilisateur. Tout se qui a un connecteur dans /dev est un périph user space, zfs est donc user space.

 
N'importe quoi. Bon je vais m'arrêter là.

 
Pas convaincu ? Tu devrais l'être pourtant.  
Même si c'est pas une référence, le tableau est valide : https://en.wikipedia.org/wiki/User_space
ZFS dans son implémentation est une interface d'accès au bare metal passant par VFS. La base même de ZFS étant la séparation des privilèges. De plus le kernel mode même en mode "mémoire" est en ring 0 et tout se qui tourne en ring 0 peut tout faire sur le système, ce n'est pas le cas de ZFS. C'est illustré dans la page platform code différences d'open ZFS et décrit très clairement quand tu analyse le code, ZFS est un wrap autour de VFS.
 
Bref, ZFS ne répond pas aux critères du kernel space, c'est donc forcément quelque chose qui tourne dans le user land, au même titre qu'un driver de carte graphique qui possède deux composants : un module KMS et un module user space. C'est justement cette séparation qui a permis a ZFS de se retrouver en "natif"

 
ZFS est en dessous de la VFS pas au dessus.
 

Non il est au dessus.

D'ailleurs ton histoire de driver est fausse aussi, un driver ça tourne dans le kernel aussi [1]. En fait tu confonds, pour toi kernel = ring0 exclusivement, alors que c'est plutôt, user = ring3. Tu confonds aussi interface et user space. Oui, une interface est utilisable en user space, mais elle sert à accéder à des informations que le kernel veut bien mettre à disposition. C'est le but d'ailleurs, n'importe quel cours d'OS t'expliquera ça.

https://github.com/illumos/illumos- [...] mon/fs/zfs

uts/ c'est le kernel dans illumos. Pourquoi mettre zfs dans uts/common/fs/zfs si zfs fait pas partie du noyau ?

Jsais pas, mets un panic au début de zfs_read, rebuild, fais un read, et tu verras un kernel panic. Explique-moi comment un process peut provoquer un panic (sauf exploitation évidente de bug kernel... donc ce qu'on vient d'introduire).

[1] sauf microkernel mais là on parle de Solaris, Illumos, Linux, BSD... Enfin surtout Linux. Et Tanenbaum et Torvalds en ont assez discuté, Linux n'est pas un microkernel