ext2, ext3 : "vider" le cache disque ?

9 réponses
Avatar
Philippe Naudin
Bonjour,

Est-il possible, via le shell, de forcer la relecture d'un fichier qui
est d=E9j=E0 "cach=E9" en m=E9moire ?

Je pense en particulier au cas o=F9 on souhaite v=E9rifier l'int=E9grit=E9
(md5sum par exemple) d'un fichier qu'on vient de copier.

Merci,

--=20
Philippe Naudin

9 réponses

Avatar
Emmanuel Florac
Le Mon, 28 May 2012 14:31:18 +0200, Philippe Naudin a écrit:


Est-il possible, via le shell, de forcer la relecture d'un fichier qui
est déjà "caché" en mémoire ?

Je pense en particulier au cas où on souhaite vérifier l'intégrité
(md5sum par exemple) d'un fichier qu'on vient de copier.



Tu peux purger le cache globalement, c'est un peu bourrin:

echo 3> /proc/sys/vm/drop_cache

Cela étant je ne comprends pas bien le but de la manoeuvre: vérifier que
ton disque dur ne se mélange pas les bits?

--
The question of whether computers can think is just like the question
of whether submarines can swim.
Edsger W. Dijkstra
Avatar
Nicolas George
Philippe Naudin , dans le message , a
écrit :
Je pense en particulier au cas où on souhaite vérifier l'intégrité
(md5sum par exemple) d'un fichier qu'on vient de copier.



La manière de procéder pour ce genre de test dépend du composant précis que
tu soupçonnes d'être défectueux.
Avatar
Philippe Naudin
Le lun. 28 mai 2012 12:34:05 CEST, Emmanuel Florac a écrit:

Le Mon, 28 May 2012 14:31:18 +0200, Philippe Naudin a écrit:


> Est-il possible, via le shell, de forcer la relecture d'un fichier qui
> est déjà "caché" en mémoire ?
>
> Je pense en particulier au cas où on souhaite vérifier l'intégrit é
> (md5sum par exemple) d'un fichier qu'on vient de copier.

Tu peux purger le cache globalement, c'est un peu bourrin:

echo 3> /proc/sys/vm/drop_cache



Ça répondrait pile-poil à mon besoin, mais ne semble pas fonctionner
chez moi.
$ uname -a
Linux TRANKIL.chezmoi 2.6.18-308.4.1.el5 #1 SMP Tue Apr 17 17:08:00 EDT 201 2 x86_64 x86_64 x86_64 GNU/Linux

Je copie +/- 200 Mo sur une clé USB, je démonte puis remonte.

## première lecture :
$ /usr/bin/time md5sum -c ~/toto > /dev/null
0.29user 0.13system 0:08.13elapsed 5%CPU (0avgtext+0avgdata 688maxresiden t)k
0inputs+0outputs (0major+199minor)pagefaults 0swaps
Huit secondes.

## nouvelle lecture sans vider le cache
$ /usr/bin/time md5sum -c ~/toto > /dev/null
0.27user 0.08system 0:00.36elapsed 99%CPU (0avgtext+0avgdata 688maxreside nt)k
0inputs+0outputs (0major+199minor)pagefaults 0swaps
Résultat immédiat, donc depuis le cache.

## vidange du cache puis nouvelle lecture :
echo 3> /proc/sys/vm/drop_caches # (en étant root)
$ /usr/bin/time md5sum -c ~/toto > /dev/null
0.25user 0.11system 0:00.36elapsed 99%CPU (0avgtext+0avgdata 688maxreside nt)k
0inputs+0outputs (0major+199minor)pagefaults 0swaps
Résultat immédiat là aussi.

La commande free ne montre aucun changement après vidange du cache.

Cela étant je ne comprends pas bien le but de la manoeuvre: vérifier que
ton disque dur ne se mélange pas les bits?



Tout à fait (à ceci près qu'il s'agit d'un support amovible), lorsque
je veux être raisonnablement sûr de ma copie.

--
Philippe Naudin
Avatar
Nicolas George
Philippe Naudin , dans le message , a
écrit :
Tout à fait (à ceci près qu'il s'agit d'un support amovible), lorsque
je veux être raisonnablement sûr de ma copie.



Alors le plus simple et le plus fiable est de débrancher puis rebrancher. La
perte d'alimentation permet de détecter des problèmes qui ne le seraient pas
autrement.
Avatar
Philippe Naudin
Le lun. 28 mai 2012 13:03:57 CEST, Nicolas George a écrit:

Philippe Naudin , dans le message , a
écrit :
> Je pense en particulier au cas où on souhaite vérifier l'intégrit é
> (md5sum par exemple) d'un fichier qu'on vient de copier.

La manière de procéder pour ce genre de test dépend du composant pr écis que
tu soupçonnes d'être défectueux.



En fait, je ne soupçonne pas spécialement un défaut, je souhaite juste
avoir le plus de garanties possibles que ma copie sur un support,
amovible ou pas (mais en excluant les montages réseau), est conforme à
l'original.

Tu procèdes comment ?

--
Philippe Naudin
Avatar
Pascal Hambourg
Philippe Naudin a écrit :
Le lun. 28 mai 2012 12:34:05 CEST, Emmanuel Florac a écrit:

echo 3> /proc/sys/vm/drop_cache



Ça répondrait pile-poil à mon besoin, mais ne semble pas fonctionner
chez moi.



Avec un espace entre 3 et >, ça devrait mieux marcher.
Avatar
Philippe Naudin
Le lun. 28 mai 2012 15:35:00 CEST, Pascal Hambourg a écrit:

Philippe Naudin a écrit :
> Le lun. 28 mai 2012 12:34:05 CEST, Emmanuel Florac a écrit:
>>
>> echo 3> /proc/sys/vm/drop_cache
>
> Ça répondrait pile-poil à mon besoin, mais ne semble pas fonction ner
> chez moi.

Avec un espace entre 3 et >, ça devrait mieux marcher.



Chuis une bille !

echo 3 > /proc/sys/vm/drop_caches

... et ça marche, comme le montrent mes tests avec md5sum et aussi la
commande free.

Merci à tous,


--
Philippe Naudin
Avatar
Emmanuel Florac
Le Mon, 28 May 2012 18:03:42 +0200, Philippe Naudin a écrit:


Chuis une bille !

echo 3 > /proc/sys/vm/drop_caches




Ben non, désolé c'est moi qui ai tapé la commande de mémoire sans
vérifier, il manquait le s à "drop_caches" mais l'espace après le 3 est
évidemment optionnelle!

--
That ideas should freely spread from one to another over the globe,
for the moral and mutual instruction of man, and the improvement of his
conditions, seems to have been peculiarly and benevolently designed by
nature, when she made them, like fire, expansible over all space,
without lessening their density in any point, and like the air in which
we breathe, move, and have our physical being, incapable of confinement
of exclusive appropriation. Inventions then cannot, in nature, be a
subject of property.
Thomas Jefferson.
Avatar
Nicolas George
Emmanuel Florac , dans le message
<4fc3a3f3$0$6821$, a écrit :
mais l'espace après le 3 est
évidemment optionnelle!



Non. Avec l'espace, ça écrit 3 sur la sortie standard. Sans, ça écrit rien
du tout sur le file descriptor 3.