augur: ha ouais
Z: ouais sauf que la, mailman a pas aimé du tout
dédicasse à augur:
[cpp]9:14:43 AM
blabla
un scrub ZFS ça permet de reconstruire un pool en cas de problème...
9:14:49 AM
blabla
ça bouffe des ressources à mort
9:15:10 AM
blabla
on fait un scuz quand tu as une erreur sur zpool status
9:15:19 AM
blabla
et encore, normalement, zfs s'auto-répare (c'est un peu le but)
9:15:35 AM
blabla
ça explique pourquoi j'ai 0.30+ de bruit de fond en LA sur ma VM
9:15:56 AM
blabla
et que ma VM était freezé hier soir
9:16:44 AM
blabla
j'ai cru voir passer un mail hier soir comme quoi y'a eu des modifications sur ZFS... Toutes modifications sur ZFS sont prise directement et pas au reboot.
9:16:57 AM
blabla
de plus, le L2ARC c'est du cache de second niveau, c'est du cache disque SSD
9:17:41 AM
blabla
y'a 2 types de cache dasn zfs: 1. ARC (gestion mémoire) qui se remplie au fur et à mesure de l'utilisation et qui s'écrit progressivement sur le disque dur , c'est une gestion de cache dynamque
9:17:56 AM
blabla
quand l'OS a besoin de RAM, ZFS s'auto-régule et diminue l'ARC
9:18:22 AM
blabla
ensuite, il y a le L2ARC qui permet de vider l'ARC standard pour aller se foutre sur les SSD et profiter de l'écriture 3GB/s
9:18:49 AM
blabla
le L2ARC doit impérativement être séparé du pool principal de disque
9:18:56 AM
blabla
sinon, ça fout la grouille.
9:19:20 AM
blabla
le dernier cache utilisé, c'est le cache ZIL (LOG) qui permet d'augmenter la vitesse d'écriture
9:19:47 AM
blabla
il écrit les données en cache sur un pool SSD qui sont réécrit au fur et à mesure sur des disques physique
9:22:50 AM
blabla
pour info, le checksum n'est pas fait sur les fichiers mais sur les blocks. ZFS c'est pas un ext4 ou je sais pas quoi
9:23:01 AM
blabla
c'est basé sur un btree
9:23:15 AM
blabla
chaque donnée est rangé à la suite et linké sur un tree dynamique
9:23:51 AM
blabla
le checksum (sha256 ou fletcher) est là pour la vérification des données et accessoirement - en cas de dedup - gagner un peu de place.
9:23:58 AM
blabla
heureusement que c'est pas du md5...
9:28:31 AM
blabla
ah autre chose, c'est du kernel land. Donc, oui, c'est normal que les I/Os souffrent si il y a un scrub ou autre. ZFS récupère les infos et lance un checksum dessus, donc, y'a de forte chance que les I/Os explosent dans ces cas là
9:28:50 AM
blabla
habituellement, on fait un scrub à froid et pas quand y'a des clients connectés [/cpp]
en l'occurence c'est sur un serveur de virtu proxmox
ping