XigmaNAS

Bonjour,

Je parcours ce forum et pas mal d'autres au sujet de ZFS, mais je me pose encore des questions au sujet de quelques fonctionnalités et options de ZFS dont j'ai du mal, malgré mes très nombreuses recherches et lectures, à saisir la/les fonctions. Je m'aime pas mettre en œuvre une solution, sans savoir ce que je fais et hors de question de suivre bêtement un tuto.

Je me suis construis mon petit nas avec 3*2To de WD RED, en raidz1 avec un spare, 6Gb de RAM, le tout avec une installe embedded avec swap et partition data sur clé usb.

Ceci dans un but domestique.

Bon, on vas commencer doucement :

-1° La partition "data", sert-elle à stocker de la data perso ou à mettre plutôt les logs de ZFS dessus. Le cas échéant, de combien de place à besoin ZFS pour ses logs et en cas de crash peut-on les récupérer facilement avec une debian de base par exemple? La clé est bien entendu formatée en "UFS".

-2°Lorsque je créé mon utilisateur, quel shell de login dois-je mettre pour une connexion ssh via putty, sachant que je fait une élévation via "su -" après?

-3° La commande "man" ne fonctionne pas, "command not found". Assez embêtant quand même, alors quelle existe sur freebsd. Il y as t'il un alias ou autre pour la remplacer?

-4°Les "acces-times", qui je cite "permettant de mettre a jour les dates d'accès au fichiers, cela génère beaucoup de lecture/écriture." soit mais je ne comprend pas l'intérêt ou non de cette fonctionnalitée. Ca me fait penser au bit d'archivage.. Si c'est ça, je ne vois pas en quoi celà génère beaucoup de lecture/écriture? Si modification il y as eu, c'est normal que le système l'enregistre. Dans ce cas rien de choquant au niveau accès-disque.. Voilà le tuto d’où c'est tiré (à la fin).

-5°Les Datasheets..sont-ils des équivalents à des "dossiers/partitions" sans limite de taille (sauf si quotas appliqué), et à part la taille physique des disques?

-6°Si quelqu'un à un petit retour à me faire sur la compression. (amputation des perfs à la lecture(film ou autre), bon compromis,...)

-7°Concernant la dé-duplication, un post de mtiburs sur ce forum linux me fait croire que cela n'est utile que pour les gros fichiers, style VMs identiques. Est-ce que cela joue uniquement sur les fichiers strictement identique? Cela peut être intéressant pour certains type de fichiers??!

-8°Concernant les snapshots, j'en connais le principe avec VmWare, qui fait un clone de la VM à un instant "T", mais pour ZFS à ce que j'ai compris, il fait une copie de son index (à un instant "t"aussi). Mais je ne saisi pas comment une copie d'index peut contribuer à assurer l'intégrité des données.

Voila pour l'instant les quelques petits détails qui me coincent pour ma compréhension globale sur nas4free.

Merci à ceux qui prendront le temps de me lire et de m'apporter quelques réponses ou débuts de réponses.

Si vous avez des liens vers des docs, je privilégie les docs en français si possible.

Merci.

Je vais me répondre à moi même pour 2-3 choses car je viens de trouver un blog qui parle beaucoup de zfs (en fouillant dedans on trouve beaucoup de chose intéressantes) .

Pour la compression Je vais utiliser "LZ4" qui à l'air pas mal et pas gourmand en ressources. J'utiliserai le gzip que en cas d'archivage et ce, sur un pool ou support différent.

Pour la dé-duplication, je vais passer mon tour pour des question évidente de hardware nécessaire à sa mise en œuvre, complétement disproportionné pour mon utilisation. Mais par contre je vais un peu creuser du côté cache (primaire et secondaire) pour les métadonnées et l'2arc.

Pour les snapshots j'ai pas encore tout saisi malgré les explications contenu dans le blog.

Est-ce que la réplication avec forte compression peut être une bonne idée pour l'archivage?

En français, un embryon
http://www.fr.sysadmin-cookbook.net/zfs/
En anglais, la bible
http://docs.huihoo.com/opensolaris/sola ... index.html
et plus spécifiquement:
http://docs.huihoo.com/opensolaris/sola ... 06s03.html

Merci pour la doc. Je vais étudier ça ce week-end.

darius28 wrote:Pour la dé-duplication, je vais passer mon tour pour des question évidente de hardware nécessaire à sa mise en œuvre, complétement disproportionné pour mon utilisation. Mais par contre je vais un peu creuser du côté cache (primaire et secondaire) pour les métadonnées et l'2arc.

Bonjour Darius28,

Je vois qu'on est plusieurs a se poser les mêmes questions

Pour la déduplication, je vais poster bientôt un retour d'expérience (matos et façon de faire)

Pour les question que vous vous posez sur ZFS, je vous conseille la chose suivante:
- recherchez la doc en français ZFS-Oracle-Documentation (http://docs.oracle.com/cd/E19253-01/820 ... index.html) et appliquez les exemples, la démarche et longue mais le résultat sera au rendez-vous. Nas4Free permets de faire beaucoup de chose en ligne de commande, personnellement je n'utilise pas l'interface web pour la configuration de ZFS, je fais tout à la main.
Attention ! je ne dis pas qu'il faut faire cela pour tout le monde surtout sur N4F, mais arrivé a un niveau et quand on est à l'aise en Linux, il faut prendre les commandes directement.
Je crois avoir lu que vous connaissiez Debian, dans ce cas, installez ZFS-fuse et jouez avec ZFS avec des fichiers, c'est tout simple et on ne prends aucun risque.

Mais en tout cas, les questions sont bonnes

Sinon pour répondre:
1- Je n'utilise jamais la partition "data" (mon avis): les données c'est sur un ou des pools.
Entre une clef (qui claque sans prévenir) et un raidz ... le choix est vite fait.
Pour les logs, je ne sais pas quoi répondre, ils se trouvent dans /var/log donc pas dans la clef, donc, en cas d'arrêt ... oû ça va ???
2- Pour l'utilisateur, je choisis toujours bash (ou sh), pour être au plus proche de Linux. Pour le root, l c'est figé: c'est zsh.
3- Je pense que man n'est pas installé pour des questions de place. Beaucoup de commandes sont commune mais il peut y avoir des différences par exemple, la commande du n'utilise pas le même argument pour la profondeur des répertoires: -d 0 / --max-depth=0
4- Les atime peuvent être un problème sur des disques SSD (ou éventuellement) pour les performances. Dans le cas d'un SSD pour le stockage il vaut mieux ne pas mettre les atime, ça fera autant d'écriture en moins sur les cellules du SSD. Je dirais que tant qu'on est pas confronté a cette problématique, autant y laisser.
5- on dit dataset voir la réponse sur la doc Oracle
6- la compression dépendra du dictionnaire utilisé et de la mémoire cache du processeur (j'ai des vieux quad-cores en 775 avec 12Mo de cache qui tartinent bien)
Pour la vidéo, je pense que la compression est à proscrire, le gain est trop faible, de plus la vidéo est nativement compressée par des algorithmes spécialisés qui laissera peut de répits à un compresseur normal.
7- J'en parlerai dans mon futur post, mais la dé-duplication n'est pas une chose a prendre "à la légère", il faut comprendre ce qu'on dé-duplique. Quand on sait ce qu'on fait, c'est génial, sinon, c'est catastrophique comme c'est pas permis. Les posts avec le titre "mythe ou réalité" sont bien vrais.
Pour répondre: oui, il faut des blocs identiques pour du matériels légers.
8- un snapshot "verrouille" une zone de données, les données suivantes s'ajouteront. Les snapshots consomment beaucoup de place, d'oû le gigantisme de ZFS
(100Go+snapshot, puis on éfface les 100Go: il restera 100Go d'occupé sur le disque alors qu'en "données" il n'y a plus rien, il suffit d'aller dans .zfs/snapshot du dataset et on retrouve les 100Go de données (elles sont toujours là), on peut d'ailleurs se balader dans le temps de cette manière, mais attention le snapshot est sur le pool, donc si on perd le pool, on perd les snapshots ... enfin ... plutôt

Bonjour,

"8- un snapshot "verrouille" une zone de données, les données suivantes s'ajouteront. Les snapshots consomment beaucoup de place, d'oû le gigantisme de ZFS
(100Go+snapshot, puis on éfface les 100Go: il restera 100Go d'occupé sur le disque alors qu'en "données" il n'y a plus rien, il suffit d'aller dans .zfs/snapshot du dataset et on retrouve les 100Go de données (elles sont toujours là), on peut d'ailleurs se balader dans le temps de cette manière, mais attention le snapshot est sur le pool, donc si on perd le pool, on perd les snapshots ... enfin ... plutôt "

"un snapshot "verrouille" une zone de données" : oui

"les données suivantes s'ajouteront": les données modifiées et les données non verrouillées s'ajouteront mais seules les modifiées font croitre par duplication.

"Les snapshots consomment beaucoup de place" : Tant qu'il n'y a pas de modification dans la zone figée espace DATA + SNAPSHOTS = espace DATA

"100Go+snapshot, puis on efface les 100Go: il restera 100Go d'occupé sur le disque alors qu'en "données" il n'y a plus rien"
D’où l'intérêt du snapshot de pouvoir récupérer 100Go de données instantanément.

"mais attention le snapshot est sur le pool, donc si on perd le pool, on perd les snapshots" OUI car un snapshot n'est pas une sauvegarde, c'est juste une possibilité de retour arrière rapide ce qui implique que le snapshot doit avoir une durée de vie courte et être effectué quotidiennement .
Une bonne pratique est la capture automatique journalière avec une durée de vie d'une semaine des snapshots ET une SAUVEGARDE hebdomadaire.
Dans ce cas l'espace disque supplémentaire se limite à la taille des blocs modifiés sur une semaine.