Lire à partir d'un disque4.3 est très lent comparé à un accès à la mémoire physique. De plus, il est fréquent de lire la même partie du disque plusieurs fois pendant des périodes relativement courtes. Par exemple, on peut d'abord lire un message e-mail, puis lire la lettre dans un éditeur lorsqu'on lui répond et ensuite refaire lire cette lettre par le programme de mail lorsqu'il la copie dans un dossier. Considérons aussi le nombre de fois où la commande ls peut être lancée sur un système avec beaucoup d'utilisateurs. En lisant l'information sur le disque seulement une fois, on peut accélérer toutes les lectures, sauf la première. Ceci est appelé cachage du disque, et la mémoire utilisée pour cela est appelée tampon cache.
Comme, malheureusement, la mémoire est une ressource finie, voire rare, le tampon cache ne peut généralement pas être assez gros (il ne peut contenir toutes les données dont on a besoin). Lorsque le cache est plein, les données inutilisées les plus anciennes sont retirées ce qui libère de la place pour de nouvelles données.
Le cachage du disque fonctionne aussi pour les écritures. Une donnée qui est écrite est souvent relue (par exemple, un fichier de code source est sauvé dans un fichier, puis relu par le compilateur), et donc mettre la donnée qui est écrite dans le cache est une bonne idée. De plus, en mettant uniquement la donnée dans le cache et en ne l'écrivant pas sur le disque tout de suite, le programme qui écrit va plus vite. Les écritures peuvent alors être faites en arrière-plan, sans ralentir les autres programmes.
La plupart des systèmes d'exploitation utilisent les tampons caches (bien qu'ils puissent être appelés autrement), mais ils ne fonctionnent pas tous selon les principes décrits ci-dessus. Certains sont write-through : les données sont écrites sur le disque immédiatement (elles sont aussi gardées dans le cache, bien sûr). Le cache est dit write-back si les écritures sont faites plus tard. Cette dernière méthode est plus efficace que la première, mais est aussi plus dangereuse : si la machine se plante, ou si l'alimentation est coupée au mauvais moment, ou si la disquette est ôtée du lecteur avant que les données du cache en attente d'écriture aient été écrites, les changements dans le cache sont en général perdus. Ceci peut même signifier que le système de fichiers (s'il y en a un) n'est pas en état de marche, peut être parce que les données non écrites comprenaient des modifications importantes des informations de gestion de celui-ci. Pour cette raison, on ne doit jamais couper l'alimentation sans utiliser une procédure d'arrêt appropriée (voir le chapitre 5), ou ôter une disquette du lecteur tant qu'elle n'a pas été démontée (si elle était montée). De la même façon, on doit attendre qu'un programme quel qu'il soit et qui l'utilisait ait signalé qu'il s'était terminé et que la diode du lecteur ne soit plus allumée. La commande sync vide le tampon, i.e, force toutes les données non écrites à être transférées sur le disque, elle peut être utilisée lorsqu'on veut être sûr que tout ait été correctement écrit. Dans les systèmes UNIX traditionnels, il existe un programme appelé update qui s'exécute en arrière-plan et qui réalise un sync toutes les 30 secondes, il n'est donc généralement pas nécessaire d'utiliser sync. Linux possède un démon supplémentaire, bdflush, qui réalise une synchronisation moins parfaite plus souvent afin d'éviter les blocages temporaires dus aux importants échanges avec le disque que sync cause quelquefois. Sous Linux, bdflush est lancé par update. Normalement, il n'y a pas à s'en occuper, mais si bdflush meurt pour une raison quelconque, le noyau préviendra et on pourra le relancer manuellement (/sbin/update).
Le tampon ne cache pas les fichiers mais les blocs, qui sont les plus petites unités d'échange avec le disque (sous Linux, ils font généralement 1 Ko). De cette façon, les répertoires, les super-blocs et les données de gestion du système de fichiers ainsi que les disques sans systèmes de fichiers sont aussi cachés.
L'efficacité d'un cache est d'abord décidée par sa taille. Un petit cache est presque inutile : il contiendrait si peu de données que toutes les données cachées seraient vidées avant d'être réutilisées. La taille critique dépend du nombre de données lues et écrites, ainsi que du nombre de fois où la même donnée est accédée. La seule façon de savoir est de faire des essais.
Si le cache a une taille fixe, il n'est pas très bon qu'il soit trop gros, car cela peut réduire la mémoire disponible et provoquer du swapping (ce qui ralentit). Pour utiliser le plus efficacement possible la mémoire réelle, Linux utilise automatiquement tout la mémoire RAM disponible pour le cache, mais réduit aussi automatiquement la taille du cache quand les programmes ont besoin de plus de mémoire.
Sous Linux, on n'a rien à faire pour utiliser le cache, tout se passe automatiquement. Mis à part suivre les procédures correctes d'arrêt et d'éjection des disquettes, on n'a pas à s'en soucier.