Salut sous conseil d'une IA :
Salut,
La config tient debout globalement, mais il y a trois points à corriger avant de commander — dont un qui touche directement ton plan de migration.
1. Le calcul de capacité ne tombe pas juste
En RAIDZ2, l'utile = (N − 2) × taille du plus petit disque du vdev. Selon l'hypothèse la plus probable (6 × 8 To) :
| Étape | Disques | Brut | Utile (To) | Utile (Tio, ce qu'affiche TrueNAS) |
|---|
| Départ | 6 × 8 To | 48 To | 32 To | ≈ 29 Tio |
| Après ajout | 7 × 8 To | 56 To | 40 To | ≈ 36 Tio |
Donc ni 48 ni 58 To utiles. Si les 58 To sont une cible utile, il faut viser autre chose : 6 × 14 To (56 To utiles), 7 × 12 To (60 To), ou 5 × 20 To (60 To). Précise ce que tu comptes acheter comme disques, ça change tout le reste.
Piège majeur : le disque récupéré de l'ancien NAS fait 8 To. La doc OpenZFS est explicite — le disque ajouté doit être au moins aussi gros que le plus petit membre du vdev. Si tu pars sur des 12 ou 14 To, ton 8 To sera tout simplement refusé. Le plan « je récupère le 8 To plus tard » ne fonctionne que si tout le vdev est en 8 To.
2. RAIDZ Expansion : ça marche, mais lis les petites lignes
La fonction existe depuis OpenZFS 2.3.0, intégré dans TrueNAS 25.04 (Fangtooth). Donc oui, ton plan « 6 disques puis +1 » est faisable. Deux réserves :
- Les anciens blocs conservent leur ratio données/parité d'origine ; seuls les blocs écrits après l'expansion utilisent le nouveau ratio. Concrètement, tes 30 To transférés depuis l'ancien NAS resteront en 4+2 même sur un vdev à 7 disques → tu ne récupères pas les 8 To attendus tant que tu n'as pas réécrit les données (script de rebalance, ou send/receive).
- L'espace libre remonté par
zfs list / df sera légèrement faux après expansion.
Alternative plus propre, puisque tu as de toute façon une copie source pendant la migration : créer directement le vdev en 7 disques avec un fichier sparse en 7ᵉ membre, l'offline immédiatement, copier les données, puis le remplacer par le vrai 8 To.
truncate -s 8T /mnt/tmp/fake.img
zpool create tank raidz2 /dev/sd{a..f} /mnt/tmp/fake.img
zpool offline tank /mnt/tmp/fake.img && rm /mnt/tmp/fake.img
# copie des données (pool dégradé mais encore 1 parité)
zpool replace tank /mnt/tmp/fake.img /dev/sdg
Tu obtiens un vdev 7-wide natif, sans dette de ratio de parité. Contreparties : CLI uniquement (non supporté par iX), et une seule parité pendant toute la copie — acceptable ici puisque l'ancien NAS reste la source.
3. Corrections matérielles
Jonsbo N3 : ce n'est pas un 5/6 baies, c'est un 8 × 3,5" + 1 × 2,5", Mini-ITX uniquement, alimentation SFX 105 mm max — pas d'ATX. Bonne nouvelle : 8 baies te laissent de la marge. Si tu voulais vraiment 5 ou 6 baies, c'est le N2 (5) ou le N4 (6, et il accepte le mATX).
N100/N150 : simple canal, 16 Go maximum, pas d'ECC, 9 lignes PCIe 3.0.
- 16 Go n'est pas un choix mais un plafond. Pour du stockage pur en SMB/NFS c'est très correct (l'ARC tiendra sur 10 Go). Si tu ajoutes Jellyfin + la galaxie *arr, ça devient juste.
- Pas d'ECC : débat sans fin, mais à assumer explicitement sur 40+ To de données. Si c'est rédhibitoire, il faut changer de plateforme (Ryzen 5600G + B550 avec ECC unbuffered, ou Xeon-D d'occasion), au prix de +10 à 15 W d'idle.
- Les 9 lignes PCIe sont vite mangées : 2 pour le contrôleur SATA, 2 pour les i226, le reste pour le M.2. Vérifie sur la fiche de la carte que le slot NVMe ne partage pas ses lignes avec des ports SATA — c'est fréquent sur les CWWK/Topton.
- Contrôleur SATA : ASM1166 (6 ports, PCIe x2) ou JMB585 (5 ports) sont OK. Fuis tout ce qui est port multiplier JMB575. Pense à mettre à jour le firmware de l'ASM1166, celui d'usine casse l'ASPM et donc les C-states — c'est la différence entre 12 W et 25 W à l'idle.
Alimentation : le vrai critère n'est pas la puissance mais le rendement à faible charge. Le système tournera à 45-55 W en régime établi, avec un pic de spin-up simultané (pas de staggered spin-up sur ces cartes) d'environ 2 A/12 V par disque. Une SFX 450-500 W de qualité (Corsair SF450, FSP Dagger Pro, Silverstone SX500) est le bon compromis. Une 750 W tournerait à 7 % de charge, rendement catastrophique.
4. Sur l'objectif « moins énergivore »
Ordre de grandeur : 10 W pour la carte N150, plus 4 à 6 W par disque 3,5" à l'idle. À 7 disques tu es à 45-55 W. Le T30 avec ses 4 disques devait tourner vers 55-70 W. Le gain est réel mais modeste, parce que ce sont les disques qui dominent, pas le CPU.
Le levier le plus efficace est donc de réduire le nombre de broches : 5 × 20 To en RAIDZ2 (60 To utiles) consomment 35 W et coûtent souvent moins cher au To que 7 × 8 To, tout en laissant 3 baies libres dans le N3 pour un futur second vdev. Ça résout aussi le problème du 8 To récupéré — qui devient alors un cold spare ou un disque de sauvegarde hors-pool, ce qui est un meilleur usage.
Points de détail
- TrueNAS SCALE s'appelle simplement TrueNAS Community Edition depuis la 25.04 ; il te faut ≥ 25.04 pour l'expansion RAIDZ.
- Boot sur NVMe : très bien, mais sauvegarde le fichier de config système, un boot pool non miroir n'est pas redondant.
- Pas de L2ARC avec 16 Go de RAM, ça mangerait de l'ARC pour rien. Pas de SLOG non plus en usage SMB domestique.
- Le refroidissement des disques dans les Jonsbo N est le point faible : remplace les ventilateurs 100 mm d'origine par des Noctua et surveille les températures HDD (< 45 °C).
- Disques : du CMR obligatoirement, et étale les achats sur plusieurs lots/revendeurs pour éviter une série entière défaillante en même temps.
- Enfin l'évidence qu'on oublie : RAIDZ2 n'est pas une sauvegarde. Pendant toute la phase de transfert, tes données n'existeront qu'en un seul exemplaire réellement fiable.
Si tu précises la taille de disques que tu vises, on peut faire le tableau exact des capacités utiles et le choix de largeur de vdev qui colle à tes 58 To.
