Dans le cas du filesystem, c'est le noyau qui s'en charge (ou plutôt le module qui gère le FS utilisé), mais dans le cas d'un SGBDR c'est le moteur du SGBD qui s'occupe de cela.
C'est bien pour ça que pendant longtemps, pour améliorer les perfs d'un SGBDR, au lieu de mettre les bases dans un gros fichier on utilisait des raw devices, c'est à dire des partitions non formattées, sur lesquelles le SGBD écrit directement ses propres données, organisées différemment d'un FS. C'était pour éviter que le noyau ne foute la grouille dans les perfs en faisant du read-ahead inutileou ce genre de choses. Le truc c'était de bypasser l'O/S qui en sait beaucoup moins que le SGBD sur la façon de manipuler les données.
Depuis, ça se fait moins, parce que les O/S ont des mécanismes qui permettent à un logiciel de dire "t'occupes pas du cache pour ce fichier, c'est moi qui m'en charge".
[^] # Re: fs VS db
Posté par peau chat . En réponse au journal Une base de données pour /home ?. Évalué à 3.
C'est bien pour ça que pendant longtemps, pour améliorer les perfs d'un SGBDR, au lieu de mettre les bases dans un gros fichier on utilisait des raw devices, c'est à dire des partitions non formattées, sur lesquelles le SGBD écrit directement ses propres données, organisées différemment d'un FS. C'était pour éviter que le noyau ne foute la grouille dans les perfs en faisant du read-ahead inutileou ce genre de choses. Le truc c'était de bypasser l'O/S qui en sait beaucoup moins que le SGBD sur la façon de manipuler les données.
Depuis, ça se fait moins, parce que les O/S ont des mécanismes qui permettent à un logiciel de dire "t'occupes pas du cache pour ce fichier, c'est moi qui m'en charge".