Reprise du message précédent :
bon apparemment c'etait un tracker. c'est de la merde ces trucs là.

adblock

ou Ghostery
enfin l'un comme l'autre ne sont pas sans poser de problèmes    

C'est pas de leur faute, la gestion du tracking a été développé par un stagiaire puis déployé à l'echelle nationale, mais le stagiaire est plus là  

Je déplore également une telle situation  

preums

Deuz

dites c'est dangereux pour un disque de l'enlever à chaud en plein fonctionnement ?  
J'aimerais tester la robustesse du ZFS d'une machine de test. Mais je n'ai quand même pas envie de niquer un disque pour rien...

¿ Oye como va ?  

 
 
Pour commencer le matin, pas mal
 

Si c'est sur un serveur avec disque hotplug ça doit passer sans souci, c'est même un test de validation assez basique
 
Si c'est une maquette sur un poste de travail je ne m'y risquerais pas

ok merci c'est un R520 donc ça doit le faire alors

Le SATA est hotplug depuis le SATA2 hein
Et certains chipset sata 1 étaient compatibles aussi

 
oui, mais bouger un disque avec les plateaux en rotation sans qu'il soit dans une "cage" c'est risqué

T'es pas obligé de le bouger pour le débrancher, le sata ça se débranche facilement.

Y a plein de trucs qui sont annoncés compatibles, mais que je ne me risque pas à tester pour autant

Faut savoir prendre des risques dans la vie
Sauf si tu bosses chez Oxalide ?
Mais plus sérieusement, je fait ça régulièrement avec du matériel grand public sans soucis

C'est surtout que je ne touche pas aux postes de travail (sauf le mien), je laisse ça à la plèbe

Débrancher l'alim d'un DD grand publique en rotation, j'évite, le sata, aucuns soucis.
Et c'est pas la couche de transport qui doit être compatible hotplug, mais le protocole utilisé (donc physiquement, SATA, IDE, etc ... Peut être compatible hotplug, mais le protocole utilisé, le DMA n'est pas hotplug, l'AHCI l'est normalement; le PIO, ça dépend). Normalement la logique SATA, tout est hotplug (depuis le SATA 1, oui oui), en pratique ça dépend du matos, de l'hba et de l'OS utilisé. Par extension toutefois, puisque le SATA3 impose le protocole AHCI, le SATA3 est hotplug, le reste ... C'est au petit bonheur (sur un chip HBA type marvell par exemple, je vérifierai a 2 fois, sur de l'intel, si c'est écrit sata3, j'y vais franco :> )

ça se passe bien  

Tu dédup quel genre de contenu ?

des working directory git d'utilisateurs, (qui bossent sur le même projet) forcement ça dédup bien
là c'est juste du test (j'ai fait un rsync depuis le serveur de prod). Et je suis aussi en train de comparer les différences de perf entre dedup=on/off comp=on/off, l'usage ram, les caches L2ARC, un SLOG sur SSD (quasiment inutile pour moi apparemment celui-là, utilisation minuscule)
 
 
je me demande aussi si je dois faire du full ZFS sur le système (avec grub-zfs) ou si je dois garder le boot et / en ext4 (je suis sous debian jessie RC1)

ZFS sur Linux marche bien alors ? J'suis toujours sur FreeBSD pour un de mes serveurs de backup.

J'ai testé BTRFS sur une autre machine, mais j'ai eu quelques mauvaises surprises.

là je suis en train de tester depuis hier et je n'ai pas eu de mauvaises surprises. Mais pour juger de la stabilité il faudrait tester sur plusieurs mois

Depusi les sources ou le .deb ? http://zfsonlinux.org/debian.html

depuis le .deb (mais le .deb compile aussi les sources sur la machine anyway, c'est du DKMS)

 
Je testerai à l'occaz

c'est moi ou le L2ARC a un "temps de chauffe" ?    
 
 
 
rsync de 70Go entre 2 dossiers sur le même pool zfs, beaucoup de (très) petits fichiers:
 
dedup=on,compression=lz4: 95m20s
dedup=off,compression=off: 63m23s
dedup=off,compression=lz4: 47m8s
dedup=on,compression=off: 37m53s
dedup=on,compression=lz4: 26m35 (second essai)
dedup=off,compression=lz4: 19m54 (second essai)
 
 

 
Temps de chauffe <_<
Se qu'il faut pas lire !

Mais non :

Indeed  

Je vous proute.
 
CDLT.
 
 

preums

deuz

"warm up time", c'est ce qui est utilisé dans la littérature scientifique sur les caches    
 
exemples:
https://www.usenix.org/system/files [...] l118_0.pdf
http://www.snia.org/sites/default/ [...] rarchy.pdf
http://lca.ece.utexas.edu/pubs/yue_sbac2004.pdf
http://www.cs.virginia.edu/~jwh6q/mrrl-web/

Ouai quand les données sont en cache ça va plus vite

je m'attendais à ce que le cache se charge au bout de 2 ou 3 copies. Car sur mon pool zfs de test je n'avais mis que ces 70Go de données, mon cache L2ARC est de 400Go et avait pleins d'espace libre.
Alors que au final la perf de mon rsync n'a progressé que progressivement (j'avais en plus déjà fait 2 copies avant de commencer mes mesures).
 
Ou alors la progression de la perf vient d'autre chose qui m'échappe...

bonsoir,

 
Non non, c'est pas quelque chose qui t'échappe et c'est bien les algos de cache, mais ZFS tu pourra commencer a voir l'impact du cache que sur une volumétrie déjà importante, et c'est pour ça que sur une maquette, bof pour mesurer l'impact du cache. Faut faire une pseudo prod (d'ailleurs pour ça que je me sert des nodes tests pour ma propre prod/privé) => passe la maquette sur la prod de ton labo.
Le cache se fait suivant trois besoins en ZFS : besoin des données récurrentes, transformation IO/Bande passante, %age d'utilisation du clust, dans une moindre mesure la taille de l'ARC/L2ARC et les profiles lecture/écriture

Preum's

dern'z