Je ne comprends pas comment cela peut être un overkill. Si c'était le cas, les caches SSD ne servirait à rien.
Le cache des SSD sert dans le sens ou il est plus rapide que le SSD lui même et permet donc d'avoir de meilleurs temps de réponses quoi qu'il arrive, également les gros cache SSD évitent que les fichiers qui sont modifiés continuellement par l'OS (au hasard /var/log/syslog) ne détruisent la durée de vie du SSD.
L'hybridation SSD/HD sert dans le sens ou le SSD est plus rapide que le HD et que l'on a des Go d'espace de stockage.
Maintenant dans le cas d'un cache classique sur un disque SATA la question est "quelle quantité de cache on peut raisonnablement remplir avant que le principe de fonctionnement du SATA ne nous oblige à faire un sync ?", question qui peut se résumer en SATA à "combien de cache va-t-on remplir avant qu'il y ait besoin de dupliquer un fichier dans le cache ?". Le SATA n'a pas de mapping des blocs, il lui est donc très difficile de faire croire à l'OS qu'il travaille sur le disque dur alors qu'il travaille en fait sur du cache. La conséquence est que le SATA n'est pas adapté du tout à la modification d'un fichier qui est déjà en cache. On peut recréer une autre entrée cache pour remplacer la première mais au moment du sync il faudra écrire les deux entrées l'une par dessus l'autre pour rester cohérent. Sur le coup on va gagner un peu de perfs, mais au sync on va doubler les I/O et là c'est le drame. (Une fois de plus je simplifie, l'OS et le NCQ font que les I/O ne sont pas vraiment doublées mais l'overhead va quand même être important).
La norme SATA fait que les disques ne sont pas très intelligent au niveau du cache, pour accéder à un cache SATA il faut demander exactement le même ségment que celui qui est dans le cache. Ou alors le segement qui est juste avant ou alors le segment qui juste après. Par exemple si dans le cache vous avez le segment xDEF -> xFFE et que vous demandez le morceau xEEA -> xEEC dans 99.9% des cas vous allez entrainer un sync/read plutôt qu'un accès cache. C'est pour ça qu'il vaut mieux parler de buffer disque plutôt que de cache dans le cas du SATA. La clef pour accéder à un segment du buffer va être une commande, ou un lot de commande plus qu'une adresse.
Sur un OS moderne, en utilisation classique avec des disques SATA, la quantité d'infos qu'il va y avoir dans le cache au moment ou ca devient contre productif de continuer à bourrer le cache plutôt que de syncer est très inférieure à 64Mo la plupart du temps. (Avant il y avait pleins de super docs qui montraient ca très bien sur le site SATA-I/O, maintenant la plus petite doc est à 25$ - cool.)
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 7.
Je ne comprends pas comment cela peut être un overkill. Si c'était le cas, les caches SSD ne servirait à rien.
Le cache des SSD sert dans le sens ou il est plus rapide que le SSD lui même et permet donc d'avoir de meilleurs temps de réponses quoi qu'il arrive, également les gros cache SSD évitent que les fichiers qui sont modifiés continuellement par l'OS (au hasard /var/log/syslog) ne détruisent la durée de vie du SSD.
L'hybridation SSD/HD sert dans le sens ou le SSD est plus rapide que le HD et que l'on a des Go d'espace de stockage.
Maintenant dans le cas d'un cache classique sur un disque SATA la question est "quelle quantité de cache on peut raisonnablement remplir avant que le principe de fonctionnement du SATA ne nous oblige à faire un sync ?", question qui peut se résumer en SATA à "combien de cache va-t-on remplir avant qu'il y ait besoin de dupliquer un fichier dans le cache ?". Le SATA n'a pas de mapping des blocs, il lui est donc très difficile de faire croire à l'OS qu'il travaille sur le disque dur alors qu'il travaille en fait sur du cache. La conséquence est que le SATA n'est pas adapté du tout à la modification d'un fichier qui est déjà en cache. On peut recréer une autre entrée cache pour remplacer la première mais au moment du sync il faudra écrire les deux entrées l'une par dessus l'autre pour rester cohérent. Sur le coup on va gagner un peu de perfs, mais au sync on va doubler les I/O et là c'est le drame. (Une fois de plus je simplifie, l'OS et le NCQ font que les I/O ne sont pas vraiment doublées mais l'overhead va quand même être important).
La norme SATA fait que les disques ne sont pas très intelligent au niveau du cache, pour accéder à un cache SATA il faut demander exactement le même ségment que celui qui est dans le cache. Ou alors le segement qui est juste avant ou alors le segment qui juste après. Par exemple si dans le cache vous avez le segment xDEF -> xFFE et que vous demandez le morceau xEEA -> xEEC dans 99.9% des cas vous allez entrainer un sync/read plutôt qu'un accès cache. C'est pour ça qu'il vaut mieux parler de buffer disque plutôt que de cache dans le cas du SATA. La clef pour accéder à un segment du buffer va être une commande, ou un lot de commande plus qu'une adresse.
Sur un OS moderne, en utilisation classique avec des disques SATA, la quantité d'infos qu'il va y avoir dans le cache au moment ou ca devient contre productif de continuer à bourrer le cache plutôt que de syncer est très inférieure à 64Mo la plupart du temps. (Avant il y avait pleins de super docs qui montraient ca très bien sur le site SATA-I/O, maintenant la plus petite doc est à 25$ - cool.)