Configurez le paramètre recordsize d’un dataset ZFS pour des documents et des fichiers multimédias mixtes en l’adaptant au schéma d’accès, et non à l’extension des fichiers. Testez les modifications sur de nouvelles écritures avant de reconstruire un partage existant.
Sur un NAS domestique, les documents, numérisations, photos, vidéos, archives et exports d’applications sont souvent regroupés dans un même partage pratique. Cette simplicité masque des schémas d’E/S différents. La décision la plus sûre concernant recordsize consiste donc soit à utiliser un réglage mixte conservateur, soit à créer des datasets distincts pour les charges de travail dont les lectures et écritures diffèrent nettement.
Vérifiez si le dataset est réellement mixte
Commencez par vérifier ce que le dataset contient réellement et comment les clients l’utilisent. Un dossier nommé Media peut également contenir des miniatures, des fichiers de sous-titres, des fichiers de projet et de petits documents, tandis qu’un partage Documents peut inclure de grandes numérisations PDF et des archives compressées.
OpenZFS présente recordsize comme une propriété de dataset et précise que ZFS utilise automatiquement des algorithmes internes pour les schémas d’accès courants. Un réglage spécifique est surtout pertinent lorsque les applications accèdent à de gros fichiers sous forme d’enregistrements de taille fixe.
Si le dataset est véritablement mixte et fonctionne déjà correctement, évitez de modifier recordsize uniquement parce qu’un autre guide recommande une valeur supérieure. La première décision consiste à déterminer si le problème actuel est réel : lectures séquentielles lentes de fichiers multimédias, mauvaise réactivité avec les petits fichiers, nombreuses modifications lors des sauvegardes, ou simple préoccupation théorique d’optimisation.
Utilisez des datasets distincts lorsque les schémas d’accès divergent clairement
Recordsize s’applique au niveau du dataset. Un seul réglage doit donc convenir à tous les nouveaux fichiers écrits dans ce dataset. Lorsque de gros fichiers multimédias et de petits documents fréquemment modifiés cohabitent, une valeur peut favoriser une charge de travail tout en rendant l’autre moins prévisible.
Klara Systems explique que la propriété recordsize d’OpenZFS définit la taille maximale des blocs logiques pour les fichiers d’un dataset, tandis que les zvols utilisent volblocksize. Cette portée au niveau du dataset explique pourquoi la séparation des charges de travail peut être plus claire que la recherche d’une valeur universelle.
Créez un dataset principalement multimédia lorsque la charge de travail consiste surtout en lectures et écritures séquentielles de grande taille, et conservez un réglage prudent pour un dataset de documents lorsque les fichiers sont petits, fréquemment modifiés ou synchronisés par de nombreux clients. Ne déplacez pas encore vos données : commencez par tester avec de nouveaux fichiers.
Modifiez recordsize avant d’écrire les données concernées
Modifier recordsize ne réorganise pas automatiquement la structure existante des fichiers. Le changement influence l’allocation des futures écritures. Modifier la propriété une fois le partage rempli ne permettra donc pas de tirer de conclusion avant que les fichiers soient réécrits ou remplacés.
Le manuel zfsprops d’OpenZFS déconseille fortement l’utilisation de recordsize pour les systèmes de fichiers polyvalents dans le contexte de l’optimisation des bases de données. C’est un rappel utile : recordsize ne doit pas être considéré comme un réglage de performance universel.
Pour un nouveau dataset, définissez la valeur souhaitée avant d’y copier les données. Pour un dataset existant, effectuez un test en copiant un dossier représentatif dans un dataset vierge avec le réglage envisagé, puis comparez la vitesse de navigation, le comportement des sauvegardes et la réactivité des clients avant de prévoir une réécriture.
Choisissez une valeur par défaut prudente pour les partages mixtes mal définis
Lorsque la charge de travail n’est pas claire, une valeur par défaut prudente est généralement plus sûre qu’une optimisation agressive. L’objectif n’est pas de maximiser un résultat de benchmark, mais d’éviter un réglage qui pénaliserait un schéma d’accès fréquent, mais moins évident.
Le guide d’administration ZFS d’Oracle décrit recordsize comme une taille de bloc suggérée et met l’accent sur son utilisation pour les charges de travail des bases de données. Cela justifie une approche prudente pour les partages de fichiers mixtes ordinaires.
Si vous ne pouvez pas encore séparer les charges de travail, conservez le dataset mixte avec la valeur par défaut de la plateforme ou une valeur modérée recommandée par votre distribution de stockage. Créez ensuite un dataset de test distinct pour les gros fichiers multimédias, plutôt que de modifier directement l’archive familiale partagée.
Vérifiez le comportement réel des clients, et pas seulement les statistiques du pool
La vérification finale doit porter sur le comportement du partage depuis les appareils qui l’utilisent réellement. Le débit global du pool peut sembler correct alors qu’une application photo, un client de synchronisation de documents ou une tâche de sauvegarde ralentit en raison de la modification du schéma d’accès.
Les discussions communautaires sur ZFS concernant les datasets multimédias et de documents distinguent souvent recordsize d’autres propriétés telles que la compression, atime et xattrs. C’est utile, car recordsize n’est qu’un des éléments à adapter à la charge de travail.
Effectuez les mêmes tâches de copie, de navigation, de modification, de numérisation et de sauvegarde que d’habitude. Conservez le nouveau réglage uniquement si la charge de travail à l’origine du changement s’améliore sans régression pour un client important. Sinon, revenez en arrière en écrivant les nouvelles données dans un dataset utilisant l’ancien réglage.
FAQ
La modification de recordsize réécrit-elle immédiatement les fichiers existants ?
Non. Considérez que la modification concerne les nouvelles écritures. Pour l’évaluer correctement, testez-la avec de nouvelles copies de données représentatives ou prévoyez une réécriture contrôlée après avoir choisi le réglage.
Les fichiers multimédias doivent-ils toujours utiliser la plus grande valeur de recordsize disponible ?
Non. Les fichiers multimédias volumineux à accès séquentiel peuvent bénéficier de blocs plus grands, mais les miniatures, fichiers de projet, métadonnées, sous-titres et accès mixtes peuvent modifier le résultat. Testez le dataset réel avant d’appliquer une règle générale.
Si la question de recordsize révèle un problème d’organisation plus vaste, commencez par séparer les charges de travail. C’est la même logique de séparation des datasets que celle utilisée pour empêcher la réplication des instantanés de remplir un pool de destination.
Assistance et conseils
Plus à lire

Guide de stockage pour l’enregistrement de la télévision en direct : capacité, conservation et nettoyage
Mesurez les enregistrements réels, prévoyez une marge de sécurité, combinez les limites d’ancienneté et de capacité, et vérifiez que le programme admissible le plus...

Flux de récupération des métadonnées multimédias à domicile après la restauration d’une base de données
Protégez l’état restauré, vérifiez l’identité et les chemins des médias, puis corrigez les illustrations ou les correspondances manquantes dans une bibliothèque pilote avant d’appliquer...

Liste de contrôle de compatibilité du client Jellyfin pour l’audio, la vidéo et les sous-titres
Testez des fichiers représentatifs en ne faisant varier qu’un paramètre à la fois, puis consignez pour chaque client la lecture directe, le remuxage, la...

