J'ai un serveur de fichiers avec un tas de disques fonctionnant ensemble dans un pool BTRFS et je veux ajouter un SSD pour la mise en cache. Je ne suis pas principalement après avoir accéléré les choses, mais je veux attraper les petits accès réguliers pour pouvoir arrêter les disques durs la plupart du temps sans utilisation intensive (ne pas les faire fonctionner 24/7 économisera de l'énergie et devrait faire les disques durent plus longtemps).
Pour autant que je sache, il existe actuellement deux techniques de mise en cache SSD mises en œuvre sous Linux, dm-cache et bcache. dm-cache est toujours dit d'être plus efficace, mais le développement se poursuit pour les deux et je n'ai pas besoin de régler pour l'efficacité maximale absolue.
En lisant la documentation de bcache , je suis tombé sur ces options:
writeback_delay : lorsque des données sales sont écrites dans le cache et qu'elles n'en contenaient pas auparavant, attend un certain nombre de secondes avant de lancer l'écriture différée. La valeur par défaut est 30.
writeback_percent : si différent de zéro, bcache essaie de maintenir ce pourcentage du cache sale en limitant l'écriture différée en arrière-plan et en utilisant un contrôleur PD pour ajuster en douceur le taux.
writeback_running : Si cette option est désactivée, l'écriture différée des données incorrectes n'aura pas lieu du tout. Les données sales seront toujours ajoutées au cache jusqu'à ce qu'il soit presque plein; uniquement destiné à l'analyse comparative. Par défaut, on.
La définition d'une valeur suffisamment grande pour writeback_delaysemble faire le travail pour moi: ne réécrivez qu'une fois par heure, ou (je suppose que cela se produirait) si le cache est plein.
Est-ce une configuration raisonnable et dois-je envisager autre chose pour réussir à faire tourner les disques? Je suis également d'accord pour suivre un itinéraire complètement différent s'il répond à mes exigences.
Il semble que @gorkypl recherche une autre solution sur un problème similaire , mais a des exigences et un environnement différents et n'a pas encore reçu de réponse.
bcache, s'il vous plaît.Réponses:
Je pense que votre approche est trop compliquée.
lire la mise en cache : rien à faire ici. Si vous avez suffisamment de RAM, cela se fait automatiquement sous Linux.
écrire la mise en cache En gros, c'est ce que vous voulez. Mais si les écritures finissent sur le disque, cela provoquera également un réveil.
Vous pouvez donc mettre les systèmes de fichiers affectés directement sur ram-disk / dev / shm ou ssd à la place.
économie d'énergie : je ne pense pas que les ralentissements / augmentations fréquents permettront d'économiser de l'énergie. Au contraire, les disques peuvent mourir plus tôt, ce qui entraîne une consommation d'énergie supplémentaire pour le processus de production. La rotation est également très consommatrice d'énergie.
la source