Matériel requis pour ZFS en 2026 : RAM, ECC, HBA, SLOG
· Dernière vérification juillet 2026
ZFS a la réputation d'exiger du matériel de serveur, et cette réputation est à moitié vraie et à moitié un folklore durci par quinze ans de fils de forum. La moitié vraie est réelle : ZFS fait avec la mémoire et les disques des choses précises que les systèmes de fichiers ordinaires ne font pas, si bien que quelques choix matériels pèsent bien plus que sur une machine ext4. La moitié folklore est justement ce qui pousse les premiers builders à trop dépenser, comme croire que ZFS dévore 1 Go de RAM par To ou qu'un scrub détruit le pool sans ECC. Ce guide sépare les deux, parcourt chaque composant qui compte vraiment pour ZFS, et se termine par quoi acheter pour trois charges de travail courantes. Si vous cherchez la vue d'ensemble, comment ZFS se compare à Unraid ou à un boîtier Synology, elle vit dans le Guide matériel NAS ; ici, nous descendons d'un cran à l'intérieur de la machine ZFS.
Comment ZFS utilise la RAM : l'ARC et le mythe du "1 Go par To"
La première chose à comprendre : ZFS traite la mémoire libre comme un cache de lecture, pas comme une marge à garder vide. Ce cache est l'Adaptive Replacement Cache, ou ARC, plus malin qu'un simple cache des données récemment utilisées, car il équilibre les données récemment utilisées contre les données fréquemment utilisées, ce qui fait qu'un pool ZFS chaud paraît vif même sur des disques mécaniques. Quand vous voyez une machine ZFS "occuper" presque toute sa RAM, c'est l'ARC qui travaille, et la mémoire est rendue dès qu'une application en a besoin. Plus de RAM achète donc surtout des lectures plus rapides, pas une plus grande marge de sécurité, si bien que la question n'est jamais "avec combien puis-je m'en tirer" mais "combien de cache vaut le prix".
Ce cadrage démonte le mythe le plus répété du monde ZFS, l'idée qu'il faut prévoir 1 Go de RAM par To de pool. Ce ne fut jamais une règle stricte, et le chiffre qui varie réellement avec la capacité est la déduplication, que le guide matériel de TrueNAS situe à environ 5 Go de RAM par To de données dédupliquées. Pour un pool normal sans dédup, ce même guide traite 8 Go comme le plancher de travail et oriente la plupart des builds vers 16 Go, si bien qu'un pool multimédia domestique de 40 To tourne parfaitement avec 16 ou 32 Go au lieu des 40 Go qu'exigerait la règle populaire. Si vous vous êtes déjà demandé où se situe ZFS face à ext4 et Btrfs sur cette question précise, notre comparatif ZFS vs ext4 vs Btrfs détaille ce que l'appétit de RAM vous achète réellement.
Là où plus de RAM paie vraiment, c'est plus étroit qu'on ne le suppose : la dédup comme ci-dessus, les pools riches en métadonnées avec des millions de petits fichiers où l'ARC dépense son budget à mettre en cache l'arborescence plutôt que les données, et les charges multi-utilisateurs ou de virtualisation où de nombreux clients sollicitent le pool en même temps et où un cache plus grand relève le taux de succès. Pour une bibliothèque Plex mono-utilisateur ou une archive photo, 16 Go suffisent largement et 32 Go sont une assurance confortable ; au-delà, vous êtes en général mieux servi en dépensant dans des disques que dans plus de barrettes. En résumé : démarrez à 16 Go pour un pool domestique, montez à 32 Go pour de nombreux utilisateurs ou VM, et ne courez après un chiffre par To que si vous activez la dédup à dessein.
RAM ECC : la version honnête d'un débat bruyant
Aucun sujet ZFS ne génère plus de chaleur que la mémoire ECC, alors voici la version calme. La mémoire ECC corrige en silence les erreurs d'un seul bit que le rayonnement de fond et les puces marginales provoquent de temps en temps, et ce avant que le bit fautif n'atteigne vos données. Cela compte pour ZFS parce que ses fameuses sommes de contrôle protègent les données à l'aller et au retour du disque, mais ne peuvent pas protéger une valeur pendant qu'elle attend en RAM d'être écrite ; si un bit y bascule, ZFS calculera fidèlement une somme de contrôle correcte pour les données désormais corrompues et stockera les deux. L'ECC comble exactement cette faille, ce qui en fait la seule mise à niveau mémoire à prendre au sérieux sur un build orienté intégrité.
Ce que l'ECC n'est pas, c'est une exigence stricte. OpenZFS lui-même décrit l'ECC comme fortement recommandée, et sa FAQ répond à la question "dois-je utiliser l'ECC" par un non clair, ajoutant que ZFS sur mémoire non ECC n'est pas plus dangereux que n'importe quel autre système de fichiers sur mémoire non ECC. Le célèbre "scrub de la mort", l'idée qu'une seule barrette défectueuse plus un scrub dégénèrent en perte totale du pool, est un mythe : un scrub ne réécrit que les blocs dont la somme de contrôle sur disque échoue vraiment, et il revérifie ses propres réparations. L'ECC vaut donc le coup sur un build dont la raison d'être est des données que vous ne pouvez pas retélécharger, et se laisse volontiers de côté sur un serveur multimédia dont le pool n'est déjà qu'une copie. Nous consacrons un article entier aux plateformes qui la prennent en charge et à sa place dans votre ordre de priorités dans RAM ECC pour NAS et ZFS. En résumé : achetez de l'ECC si les données sont irremplaçables et si la carte le permet, mais ne laissez pas son absence vous empêcher d'utiliser ZFS, car ZFS avec sommes de contrôle et sauvegarde bat toujours un système de fichiers nu sans ni l'un ni l'autre.
Donnez les disques directement à ZFS : un HBA, pas du RAID matériel
ZFS gère lui-même la redondance, les sommes de contrôle et la réparation, ce qui veut dire qu'il doit voir chaque disque physique comme un périphérique brut plutôt qu'à travers un contrôleur qui a déjà pris des décisions à sa place. Sur ce point, OpenZFS est le plus catégorique : ses notes matérielles indiquent clairement que les contrôleurs RAID matériels ne devraient pas être utilisés avec ZFS et qu'un HBA est le meilleur choix, pour la performance comme pour la fiabilité. Une carte RAID matérielle cache les disques individuels derrière sa propre logique et son propre cache, si bien que ZFS perd les données SMART directes, le contrôle des délais et le rapport d'erreurs honnête dont il dépend pour bien faire son travail.
En pratique, cela veut dire un host bus adapter, une carte dont le seul rôle est d'ajouter des ports de disque et de transmettre chaque unité telle quelle, sans y toucher. Le standard du homelab est une carte SAS LSI/Broadcom comme la Broadcom 9300-8i, un adaptateur PCIe x8 qui ajoute huit disques. Le détail à réussir à l'achat d'occasion est le firmware : beaucoup de ces cartes arrivent en mode IR (RAID intégré) et doivent être reflashées en mode IT (initiator target), ce qui retire la logique RAID et transforme la carte en simple contrôleur de passage. Une carte déjà flashée en mode IT vous épargne le reflashage, et notre comparatif RAID matériel vs logiciel explique pourquoi l'approche par passage direct est celle que veut tout build ZFS moderne.
Deux raccourcis bon marché sont à éviter pour la même raison. Le "RAID" de la carte mère, le mode Intel RST ou AMD RAIDXpert du BIOS, est du faux RAID qui cache les disques derrière un pilote, alors laissez le contrôleur SATA en AHCI simple et laissez ZFS posséder les disques. Les cartes répartitrices de ports qui promettent huit disques depuis deux ports SATA s'appuient sur des multiplicateurs de ports SATA, et OpenZFS avertit que leur prise en charge est inconstante et que des disques SATA ne devraient jamais aller dans un expandeur SAS sans interposeur SAS. En résumé : dès que vous dépassez les quatre à six ports SATA de la carte, ajoutez un vrai HBA en mode IT plutôt qu'un faux RAID ou un multiplicateur de ports, et laissez ZFS parler au métal nu.
SLOG : un ZIL séparé que seules les écritures synchrones vous remercieront d'avoir
Le SLOG est l'accessoire ZFS le plus mal compris, alors il aide de commencer par ce qu'il n'est pas. Tout pool ZFS a déjà un ZIL, le ZFS Intent Log, où le pool consigne les écritures qu'une application a demandé de rendre durables immédiatement avant de les confirmer. Un SLOG (log séparé) déplace simplement ce log des disques principaux vers un périphérique rapide et dédié, et voici le piège qui fait trébucher beaucoup de monde : il n'aide que les écritures synchrones. La référence SLOG de TrueNAS est explicite sur le fait que le ZIL ne traite pas les écritures asynchrones par défaut, si bien que les charges qui en profitent sont celles qui exigent la durabilité à chaque opération, à savoir les datastores NFS, le stockage de VM et iSCSI, et les bases de données.
Deux propriétés comptent quand vous en avez vraiment besoin. D'abord, comme le but entier d'un SLOG est de rejouer les écritures promises durables si le courant tombe au milieu de la transaction, le périphérique doit avoir une protection contre les coupures de courant, ces condensateurs embarqués qui laissent un SSD entreprise terminer ses écritures en cours après une coupure ; un SSD grand public bon marché sans eux ruine tout l'intérêt. Ensuite, il peut être petit, car il ne garde que quelques secondes d'écritures : TrueNAS suggère un périphérique de 16 Go, idéalement surprovisionné depuis un SSD à forte endurance pour répartir l'usure. Ce dont vous n'avez pas besoin, c'est d'un SLOG pour un NAS domestique qui sert des partages SMB et du multimédia, car ces écritures sont asynchrones et ne touchent jamais le ZIL, si bien que l'argent est bien mieux placé en RAM ou en disques. En résumé : ajoutez un SLOG à protection contre les coupures uniquement si vous faites tourner NFS, des VM ou des bases de données avec écritures synchrones, et sinon laissez l'emplacement vide.
L2ARC et le special vdev : un cache qui vous coûte de la RAM
Le L2ARC est le pendant en lecture du SLOG, un cache de second niveau sur un SSD qui rattrape les blocs évincés de l'ARC en RAM, et il arrive avec un coût contre-intuitif. Chaque enregistrement garé dans le L2ARC a besoin d'un petit en-tête suivi en RAM, que le guide matériel de TrueNAS situe à environ 1 Go de RAM par 50 Go de L2ARC. Voilà le piège : boulonnez un SSD de cache de 500 Go sur une machine de 16 Go et vous aurez discrètement dépensé 10 Go de votre précieux ARC en en-têtes d'index, si bien que le cache peut baisser votre taux de succès au lieu de le relever. La règle qui en découle est simple : ajoutez de la RAM avant d'ajouter du L2ARC, car la RAM est de l'ARC plus rapide et ne se taxe pas elle-même pour exister.
Le L2ARC mérite son emplacement dans un cas plus étroit, quand votre working set dépasse vraiment la RAM que vous pouvez physiquement installer et que les lectures sont assez aléatoires pour qu'un cache SSD rapide batte l'aller vers le pool. TrueNAS note qu'un périphérique L2ARC ne vaut le coup que lorsque ses IOPS en lecture aléatoire dépassent clairement le stockage primaire, si bien qu'un SSD SATA lent devant un large ensemble de disques peut être inutile. Pour la plupart des pools domestiques, vous irez plus loin en remplissant les emplacements de barrettes et en laissant le L2ARC pour le jour où la machine est vraiment limitée par la RAM.
Pour le public plus technique : il existe un troisième vdev à usage spécial qui vaut la peine d'être connu, le special vdev, une classe d'allocation dédiée qui stocke les métadonnées du pool (et, si vous le choisissez, les petits blocs sous une taille que vous fixez) sur des SSD rapides plutôt que sur le pool mécanique. Sur un pool riche en métadonnées avec des millions de fichiers, il peut transformer la vivacité des listages de répertoires et des scrubs, car les métadonnées ne rivalisent plus avec les données pour les disques lents. Le tranchant, c'est la redondance : un special vdev garde des données que le pool ne peut pas reconstruire, il doit donc être en miroir au moins au niveau de redondance du pool, et perdre un special vdev sans miroir perd le pool entier. C'est un vrai gain de réglage pour la bonne charge, mais un geste avancé à planifier à la création du pool, pas une pièce à boulonner à la légère.
Budgétiser les lignes PCIe : un exemple chiffré où elles s'épuisent
Voici la contrainte dont personne n'avertit les premiers builders ZFS, et celle qui ruine en silence les listes de pièces ambitieuses : les lignes PCIe. Une ligne est l'une des connexions à haut débit limitées du processeur vers tout ce qui n'est pas la mémoire, et comme l'explique l'aperçu de PCI Express, un processeur de bureau grand public n'expose qu'environ 20 à 24 lignes utilisables. Le chipset de la carte en ajoute d'autres, mais il les renvoie toutes au processeur par un unique lien partagé, si bien que ces lignes de chipset sont de la bande passante partagée, pas de la capacité libre. Un build ZFS est inhabituel parce qu'il veut des lignes dans plusieurs directions à la fois, et c'est là qu'une carte bon marché s'assèche.
Parcourez une liste de souhaits réaliste et comptez. Un HBA à huit ports veut un emplacement x8 complet. Une carte réseau 10GbE veut encore x4 à x8 selon le modèle. Un SSD de démarrage prend x4, et si vous avez aussi prévu un SLOG NVMe et un L2ARC NVMe, c'est encore x4 chacun. Additionnez, et les seules cartes d'extension réclament quelque chose comme x8 plus x8 plus trois x4, soit environ 28 lignes avant que le processeur n'ait rien dépensé pour le graphisme. Sur une plateforme grand public avec quelque 20 à 24 lignes de processeur, cela ne rentre pas : mettez le HBA dans le premier emplacement x16 et le second tombe en général de x16 à x8, et insérer un lecteur M.2 désactive souvent une paire de ports SATA sur la même carte. Vous finissez par choisir entre le HBA et la carte 10GbE, ou vous poussez les NVMe sur le lien partagé du chipset, où ils se disputent entre eux.
C'est la vraie raison pour laquelle les builds ZFS sérieux dérivent vers des plateformes station de travail et serveur plutôt que des cartes gamer. Un Intel Xeon E ou une puce série W, ou un AMD Ryzen sur un chipset station de travail, expose simplement plus de lignes de processeur en plus de fonctions de carte serveur comme l'IPMI pour la gestion à distance, si bien qu'un HBA, une NIC rapide et une paire de NVMe peuvent coexister sans se battre pour la même poignée de lignes. La leçon est une habitude, pas une pièce : si votre liste de souhaits inclut un HBA plus 10GbE plus le moindre NVMe, additionnez les lignes sur le papier avant d'acheter et passez à une plateforme qui les a, plutôt que de découvrir le manque une fois les colis arrivés. Une fois la plateforme réglée, vérifiez les capacités de disque et les niveaux RAID face à des modèles réels dans notre base de données de disques NAS.
Les pièces sur lesquelles un build ZFS s'appuie souvent
Le HBA et les barrettes ECC que vous choisissez dépendent de votre plateforme, donc ils vivent dans les guides liés plus haut et non en cartes uniques ici. Ce qui accompagne presque tout build ZFS, c'est la distribution de soutien ci-dessous, alors prenez-les comme des points d'ancrage et budgétisez les disques et la mémoire autour de la taille de votre pool.
Recommandation
Pour un pool domestique multimédia et de sauvegarde (Plex, photos, partages en SMB), restez sobre : 16 Go de RAM, une carte mère basse consommation, des disques CMR en RAIDZ2 à partir de quatre unités, un onduleur, et ni SLOG ni L2ARC, car les écritures asynchrones n'en utilisent jamais et votre argent achète plus de capacité. Pour une machine de virtualisation ou NFS (Proxmox, datastores ESXi, bases de données), le tableau des écritures synchrones s'inverse : prévoyez 32 Go de RAM ou plus, ajoutez un SLOG à protection contre les coupures et choisissez une plateforme avec assez de lignes PCIe pour que la NIC 10GbE et le HBA ne se battent pas. Pour un pool volumineux ou riche en métadonnées (millions de fichiers, ou dédup volontaire), menez d'abord avec la RAM (la dédup veut environ 5 Go par To), envisagez un special vdev en miroir pour les métadonnées si le goulot est la performance des répertoires, et ne recourez au L2ARC que lorsque les emplacements de barrettes sont pleins. Dans les trois cas, l'ECC est la mise à niveau à prioriser si les données sont irremplaçables et si la carte le permet, et tout ce qui précède suppose toujours la règle d'or de bitrot et scrubbing ZFS : ZFS plus une vraie sauvegarde, jamais ZFS à la place d'une.
Articles liés
Guide matériel NAS 2026 : quoi regarder selon l'OS et le système de fichiers
Carte mère NAS : ports SATA et lignes PCIe qui comptent
RAM ECC pour NAS et ZFS : obligatoire ou mythe ?
ZFS vs ext4 vs Btrfs : quel système de fichiers pour votre NAS ?
Bitrot et scrubbing ZFS : quand les données pourrissent en silence
RAID matériel vs logiciel : lequel gagne en 2026 ?