Jolie bête.
Le genre de matos qui une fois en place ne bougera plus.
C’est intéressant ces snapshots XFS, mais j’entendais un peu plus par ce terme que des copies hors-ligne de sauvegarde. Je pensais aussi à la possibilité de stocker et d’utiliser ces snapshots en ligne, genre un répertoire .snapshots/{daily.0,daily.1,etc} à la racine du FS, tout en ne prenant que l’espace disque du diff. Donc plutôt des clones copy-on-write, dans un système qui est effectivement plus qu’un FS, mais aussi un gestionnaire de volume.
J’avais déjà des fonctionnalités similaires sur des baies NetApp il y a plus de dix ans, et je trouve un peu triste que ça soit toujours si compliqué aujourd’hui 
Mais bon, comme dit, ça reste assez facultatif. Si c’est trop gourmand pour un NAS ARM à 4Go de RAM, je peux faire sans. Par contre, si quelqu’un a des chiffres sur ce qu’il faut pour faire tourner du btrfs en bonne condition, je suis preneur.
J’ai cru lire que Armbian/Debian était le système de référence chez Helios et ça me va tout à fait à priori 
C’est pour un usage assez simple de toute façon, j’ai déjà un Nextcloud qui tourne sur Internet avec un S3 en backend pour l’hébergement principal, le NAS servirait plus comme cache local de gros volumes qui dépassent la volumétrie des SSD, et faciliter les échanges entre machines sur le LAN. Je sais même pas si je vais m’emmerder à le sauvegarder.
Red Hat a pas mal travailler sur un système de fichier n’étant pas prévu pour gérer les snapshots.
Surement la limitation du à l’historique de XFS
Cela n’intéresse pas madame ou monsieur tout le monde. L’intérêt pour un utilisateur averti ça peut ce comprendre suivant son utilisation.
Moins que le ZFS, mais en fonction des realeases et des kernel Linux, ca évolue 
Rien avoir, benchmark XFS, Ext4 et BTRFS
Je connais pas trop trop les FS, mais un cache qui renvoie de la merde, c’est deja un bon depart pour une histoire d’horreur 
Bien sûr, mais un cache, FS ou autre, à priori tu vas aussi le penser pour qu’il bouffe juste assez de RAM pour prendre ses aises sans faire crasher le système en provoquant des OOM. De ce que je lis, le cache en question de ZFS (ARC) a l’air programmé pour prendre « tout sauf 1Go ». Pourtant, à arpenter les forums/Reddit/blogs sur ZFS/FreeNAS, tu lis tout et son contraire, de personnes sans aucun problème à d’autres qui parlent de pools détruites, d’OS qui refuse de se mettre à jour et de globalement refuser toute aide à des personnes avec moins de 8Go de RAM.
Pour un FS de PC en utilisation normale, l’intérêt est assez limité en effet, surtout avec juste un SSD pas forcément très gros pour travailler. Mais même sur un NAS perso, l’intérêt me semble assez évident par contre. Que ça soit compliqué à implémenter sur un FS classique par contre, probablement.
Merci pour le benchmark.
Tu parle de quelle taille de FS et combien de fichiers pour ton btrfs ? Je peux faire un test vite fait sur une VM pour donner un ordre de grandeur.
Ton message indiquant un soucis de stabilité laissait penser que tu avais potentiellement des crashs.
Pour répondre à quelque uns de tes points sur OMV :
- Effectivement un seul développeur. Je crois que c’est plus par choix que par manque de contributeur : « c’est son projet ».
- Concernant les upgrade, de manière générale j’ai toujours vu un schéma d’upgrade possible entre 2 versions majeures. Après comme tous changement de release majeure de distribution, il est préférable de faire une reinstall/reconfig. Le gros point bloquant réside souvent dans les plugins non officiels peu ou mal supportés/maintenus qui peuvent te péter ton upgrade.
- BTRFS c’est juste no way pour moi. Si jamais le support de MDADM + EXT4/XFS est abandonné, j’irai trouver autre chose. Après on n’en est pas encore là et un fork est toujours possible, à l’instar de XigmaNAS avec FreeNAS.
Je te rejoins sur ta conclusion. Le problème est que l’offre de distribution axée NAS est assez limitée. Même FreeNAS n’est pas la panacée, d’autant plus que le ZFS pour un particulier est globalement assez gourmand/contraignant (mon expérience avec le ZFS a été assez amère, j’imagine et j’espère qu’en 10 ans les choses se sont bien améliorées).
Le plus dur in fine est d’avoir une distribution « NAS » qui contente tout le monde : il y a quasiment autant d’usages que de personnes. Cela varie de simple espace de stockage réseau (NAS) à un serveur faisant office d’hyperviseur et/ou hôte de containeur type docker pour hébergé de multiples services…
Aujourd’hui, OMV, même si son GUI peut paraitre un peu austère et qu’il faut parfois mettre les mains dans le cambouis, rempli son office pour du stockage réseau.
Si on a besoin de configuration plus complexe ou de services cloisonnés, je pense qu’il est préférable de partir sur KVM (avec genre Proxmox) ou ESXi. Ca laisse le champ ouvert à toutes les possibilités.
C’est pas définitif, ça le sera quand j’aurais acheté les disques, mais ça sera un usage multimédia assez léger. À priori je penche pour un setup en RAID1 pour éviter les problèmes des RAID5/6, avec des disques d’environ 6To. Les fichiers seraient d’une taille moyenne (quelques Mo) à grosse (quelques Go), pour un nombre qui devrait tenir dans les 30 000 je dirais.
Plus ca va, plus je me dis qu’il faut que j’avance pour refaire un sujet plus propre pour les solutions de stockage homade.
3 « J'aime »
Le Helios64 est en précommande, ca fait 313$ avec les frais de port vers la france.
Moi mon paiement est revenu a 281.74€
1 « J'aime »
tu fais tourner quoi sur un helios ? NextCloud ? backup ?
Pris le mien aussi.
Pas con la batterie intégré, mais je trouve pas d’info sur le temps de maintient en fonctionnement.
Ils parlent aussi d’un système dual alim, un dc pack et l’alim ATX, mais je suis pas sur qu’un dc pack 5V usb puisse alimenter 5 HDD…
Cool 
Moi j’avais envie d’en prendre 2 voir 3. Mes finances ont eu le dernier mot
Sur le Helios4 que j’ai, c’est une ARMbian avec gestion du raid avec mdadm et partage NFS et Samba. Dessus arrive des backup de mon NAS principal et aussi le stockage des data de mon nexcloud ce trouvant sur un mini PC pour avoir un poil plus de puissance que sur le Helios4 quoi est un armv7 donc 32 bits.
Mon petit server Nexcloud, Plex, reverse proxy, monitoring, LXC/LXD et KVM.
Concernant la batterie, c’est le coté microcoupure et lissage du courant. La durée n’est aucunement communiqué car cela va dépendre si c’est un disque flash ou mécanique.
Je présume, le temps d’éteindre le NAS.
Pour la double alimentation, la réponse en image :
Tu parles de J16 et J10? Ok sauf qu’il n’y a pas la place (en tout cas, j’ai pas vu) dans le boîtier pour mettre une alim ATX compatible avec le connecteur J10, donc…
Ce n’est pas forcément pour mettre dans le boitier qui pourra s’acheter plus tard seul comme la carte mère.
Le connecteur J9 et J10, ça doit être soit alimentation style Pico ou alors la batterie de secoure.
Je verrais quand je l’aurais reçu ou que la doc soit sortie d’ici la.
En tout cas, l’alimentation dans le KIT est bien la J16
Je viens de découvrir un article très intéressant sur le site de inpact-hardware.
Le prix de 7$ par moi correspond a une machine avec 1 core. Plus de core est forcément plus chère.
La vidéo de présentation de Qnap
Et le site de Qnap
https://software.qnap.com
Je trouve ça super cher pour un particulier. Avec 1 coeur tu ne vas rien faire de plus que faire du NAS simplissime sans services et dans ce cas qu’elle est l’intérêt d’une solution QNAP qui va nécessiter un hyperviseur. Et avec plus de coeur tu paye 150+ € par an…
Ça semble être une demande auquel Qnap y répond.
Moi ce qui me gêne, c’est le côté abonnement. Cette tandance de la location pour tout et n’importe quoi me gonfle.
2 « J'aime »
Ca bouge chez ixsystems éditeur de FreeNAS. FreeNAS va devenir TrueNAS CORE.
La prochaine évolution ce nommera TrueNAS CORE 12.0 et embarquera Open ZFS 2.0
FreeNAS qui est libre et TrueNAS est vendu uniquement avec du matériel car offre des options dédié aux professionnels. Mais les deux partagent la même base. Donc les deux projet fusionnent.
Surtout que TrueCommand qui est une console de gestion unifié pour gérer des fermes de serveurs existe depuis quelques temps.