Nous avons deux disques USB "My Passport" d'un To (modèles WDBACX0010BBL
et WDBACX0010BRD). J'ai une question sur le fonctionnement des buffers
disques.
Avec l'un ou l'autre disque, monté en ntfs-g3, je lance plusieurs fois la
commande suivante :
# time tar -C $repertoire_disque -c ./ > /dev/null
La 1ère fois, elle met environ 1'10" à se terminer
Un coup d'oeil sur le site de WDt me dit que le taux de transfert peut
atteindre 480Mo/s en USB-2, ce qui est le cas de mon système.
Déjà là, on dépasse la vitesse théorique de 50% !
Mais la 2ème fois, la commande prend 12", à la 3ème 5,2", puis 4.7", etc.
La comande du se comporte de la même manière ; 1'8" puis 3.7" en
enchaînant les appels avec un disque; mais 53" puis 13" avec l'autre.
Je n'ai que 2Go de RAM, il est impossible que les données des disques
soient bufferisées là. Quelqu'un pourrait me dire si cette évolution des
temps de transfert est normale et à quoi elle est dûe dans ce cas ?
Quand tu vois un répertoire dont tu ne connais pas l'usage, tu te dis qu'on peut y écrire n'importe quoi n'importe comment ?
En fait, n'importe qui peut y écrire n'importe quoi mais pas n'importe combien car ça bloque au-delà d'1/4 de la RAM. Quant à y écrire n'importe comment : non car c'est l'OS qui se charge des E/S, hein.
à + -- Hervé
Nicolas George :
Quand tu vois un répertoire dont tu ne connais pas l'usage, tu te dis
qu'on peut y écrire n'importe quoi n'importe comment ?
En fait, n'importe qui peut y écrire n'importe quoi mais pas n'importe
combien car ça bloque au-delà d'1/4 de la RAM. Quant à y écrire n'importe
comment : non car c'est l'OS qui se charge des E/S, hein.
Quand tu vois un répertoire dont tu ne connais pas l'usage, tu te dis qu'on peut y écrire n'importe quoi n'importe comment ?
En fait, n'importe qui peut y écrire n'importe quoi mais pas n'importe combien car ça bloque au-delà d'1/4 de la RAM. Quant à y écrire n'importe comment : non car c'est l'OS qui se charge des E/S, hein.
à + -- Hervé
Nicolas George
Herve Autret , dans le message <4ecceb54$0$24197$, a écrit :
En fait, n'importe qui peut y écrire n'importe quoi mais pas n'importe
(Ceci répond également à NiKo.)
N'importe qui peut y écrire, mais ça ne veut pas dire qu'il faut le faire.
Dans le même genre, tu _peux_ supprimer le fichier ~/.Xauthority, mais si tu le fais, tu auras des problèmes.
D'une manière générale, si tu ne sais pas à quoi sert quelque chose sur le système, tu ne dois pas y toucher sans t'être renseigné.
Herve Autret , dans le message <4ecceb54$0$24197$426a34cc@news.free.fr>,
a écrit :
En fait, n'importe qui peut y écrire n'importe quoi mais pas n'importe
(Ceci répond également à NiKo.)
N'importe qui peut y écrire, mais ça ne veut pas dire qu'il faut le faire.
Dans le même genre, tu _peux_ supprimer le fichier ~/.Xauthority, mais si tu
le fais, tu auras des problèmes.
D'une manière générale, si tu ne sais pas à quoi sert quelque chose sur le
système, tu ne dois pas y toucher sans t'être renseigné.
Le Wed, 23 Nov 2011 13:17:30 +0000, Nicolas George a écrit :
Herve Autret , dans le message <4ecceb54$0$24197$, a écrit :
En fait, n'importe qui peut y écrire n'importe quoi mais pas n'importe
(Ceci répond également à NiKo.)
N'importe qui peut y écrire, mais ça ne veut pas dire qu'il faut le faire.
Dans le même genre, tu _peux_ supprimer le fichier ~/.Xauthority, mais si tu le fais, tu auras des problèmes.
Si tu touches à ce ~/.Xauthority, ça ne concerne que toi. Tu as le droit le plus strict de flinguer ton compte. Tu ne "flingueras" pas le système...
PS: Mon ".Xauthority" est vide. Il sert à quelque chose ? (dans mon cas...)
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Nicolas George
Sergio , dans le message <4eccf5b1$0$21860$, a écrit :
Si tu touches à ce ~/.Xauthority, ça ne concerne que toi. Tu as le droit le plus strict de flinguer ton compte. Tu ne "flingueras" pas le système...
Toucher /dev/shm ne fera rien de durablement grave, rien qu'un reboot ou quelques rm puisse corriger. Mais ce n'est pas pour autant une raison de faire n'importe quoi avec quand on ne sait pas.
PS: Mon ".Xauthority" est vide. Il sert à quelque chose ? (dans mon cas...)
Certains display managers mettent le contenu quelque part dans /var, avec une variable d'environnement pour le désigner.
Sergio , dans le message <4eccf5b1$0$21860$426a74cc@news.free.fr>, a
écrit :
Si tu touches à ce ~/.Xauthority, ça ne concerne que toi. Tu as le droit
le plus strict de flinguer ton compte. Tu ne "flingueras" pas le
système...
Toucher /dev/shm ne fera rien de durablement grave, rien qu'un reboot ou
quelques rm puisse corriger. Mais ce n'est pas pour autant une raison de
faire n'importe quoi avec quand on ne sait pas.
PS: Mon ".Xauthority" est vide. Il sert à quelque chose ? (dans mon
cas...)
Certains display managers mettent le contenu quelque part dans /var, avec
une variable d'environnement pour le désigner.
Sergio , dans le message <4eccf5b1$0$21860$, a écrit :
Si tu touches à ce ~/.Xauthority, ça ne concerne que toi. Tu as le droit le plus strict de flinguer ton compte. Tu ne "flingueras" pas le système...
Toucher /dev/shm ne fera rien de durablement grave, rien qu'un reboot ou quelques rm puisse corriger. Mais ce n'est pas pour autant une raison de faire n'importe quoi avec quand on ne sait pas.
PS: Mon ".Xauthority" est vide. Il sert à quelque chose ? (dans mon cas...)
Certains display managers mettent le contenu quelque part dans /var, avec une variable d'environnement pour le désigner.
Herve Autret
Nicolas George :
Dans le même genre, tu _peux_ supprimer le fichier ~/.Xauthority, mais si tu le fais, tu auras des problèmes.
On peut aussi faire rm -Rf $HOME, si on veut. Pour le .Xauthority, ça dépend de quand on l'efface (pendant une session ou hors session) ; ça dépend aussi sans doute de la version du serveur et de l'endroit où il stocke les cookies de secours, comme tu le disais à Sergio.
D'une manière générale, si tu ne sais pas à quoi sert quelque chose sur le système, tu ne dois pas y toucher sans t'être renseigné.
Flinguer des systèmes, je sais faire. Donc : ne pas toucher sans moyen de restauration indolore, ou sans avoir essayé sur un cobaye (en admettant qu'on puisse ainsi expérimenter toutes les conséquences, ce qui est en général un vaste programme).
Maintenant j'avais déjà touché /dev/shm en modifiant ses options dans le fstab, par le passé. Cette fois, j'ai juste créé un fichier dedans ; ce n'est pas la même chose. Cette ressource n'est pas dissimulée (ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi, sauf à libérer l'espace occupé dès qu'il n'est plus nécessaire ; comme on fait avec la mémoire lorsqu'on la gère explicitement dans un programme.
Quand à se renseigner : parfois on tombe mal, comme cette page qui cite ce même /dev/shm et que j'avais citée sur ce forum : http://wiki.slackware-fr.org/administration:trucs:activer_la_memoire_partagee_d_une_carte_video
Ceci étant dit, poster ici est une manière de se renseigner en lisant les remarques par exemple, non ? -- Hervé
Nicolas George :
Dans le même genre, tu _peux_ supprimer le fichier ~/.Xauthority, mais
si tu le fais, tu auras des problèmes.
On peut aussi faire rm -Rf $HOME, si on veut. Pour le .Xauthority, ça
dépend de quand on l'efface (pendant une session ou hors session) ;
ça dépend aussi sans doute de la version du serveur et de l'endroit où
il stocke les cookies de secours, comme tu le disais à Sergio.
D'une manière générale, si tu ne sais pas à quoi sert quelque chose sur
le système, tu ne dois pas y toucher sans t'être renseigné.
Flinguer des systèmes, je sais faire. Donc : ne pas toucher sans moyen
de restauration indolore, ou sans avoir essayé sur un cobaye (en
admettant qu'on puisse ainsi expérimenter toutes les conséquences, ce
qui est en général un vaste programme).
Maintenant j'avais déjà touché /dev/shm en modifiant ses options dans le
fstab, par le passé. Cette fois, j'ai juste créé un fichier dedans ; ce
n'est pas la même chose.
Cette ressource n'est pas dissimulée (ce n'est pas comme si elle
s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de
raison de prendre des précautions quant à son emploi, sauf à libérer
l'espace occupé dès qu'il n'est plus nécessaire ; comme on fait avec
la mémoire lorsqu'on la gère explicitement dans un programme.
Quand à se renseigner : parfois on tombe mal, comme cette page qui cite
ce même /dev/shm et que j'avais citée sur ce forum :
http://wiki.slackware-fr.org/administration:trucs:activer_la_memoire_partagee_d_une_carte_video
Ceci étant dit, poster ici est une manière de se renseigner en lisant
les remarques par exemple, non ?
--
Hervé
Dans le même genre, tu _peux_ supprimer le fichier ~/.Xauthority, mais si tu le fais, tu auras des problèmes.
On peut aussi faire rm -Rf $HOME, si on veut. Pour le .Xauthority, ça dépend de quand on l'efface (pendant une session ou hors session) ; ça dépend aussi sans doute de la version du serveur et de l'endroit où il stocke les cookies de secours, comme tu le disais à Sergio.
D'une manière générale, si tu ne sais pas à quoi sert quelque chose sur le système, tu ne dois pas y toucher sans t'être renseigné.
Flinguer des systèmes, je sais faire. Donc : ne pas toucher sans moyen de restauration indolore, ou sans avoir essayé sur un cobaye (en admettant qu'on puisse ainsi expérimenter toutes les conséquences, ce qui est en général un vaste programme).
Maintenant j'avais déjà touché /dev/shm en modifiant ses options dans le fstab, par le passé. Cette fois, j'ai juste créé un fichier dedans ; ce n'est pas la même chose. Cette ressource n'est pas dissimulée (ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi, sauf à libérer l'espace occupé dès qu'il n'est plus nécessaire ; comme on fait avec la mémoire lorsqu'on la gère explicitement dans un programme.
Quand à se renseigner : parfois on tombe mal, comme cette page qui cite ce même /dev/shm et que j'avais citée sur ce forum : http://wiki.slackware-fr.org/administration:trucs:activer_la_memoire_partagee_d_une_carte_video
Ceci étant dit, poster ici est une manière de se renseigner en lisant les remarques par exemple, non ? -- Hervé
Nicolas George
Herve Autret , dans le message <4ecd0390$0$681$, a écrit :
On peut aussi faire rm -Rf $HOME, si on veut.
La différence avec mon exemple, c'est que supprimer $HOME, on devine immédiatement quel effet néfaste ça va avoir, alors que vire .Xauthority, un fichier au nom abscons dont 99% des utilisateurs n'ont jamais entendu parler, l'effet saute moins aux yeux.
Cette ressource n'est pas dissimulée
Il y a plein de choses dissimulées : essaie de passer /dev/mem en mode 0666 puis d'écrire dedans qu'on rigole.
(ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi
Un jour, tu auras un problème avec un programme qui ne fonctionne pas sans que tu saches pourquoi, et après avoir perdu des heures à chercher tu comprendras pourquoi tu n'aurais pas dû toucher à /dev/shm.
Ceci étant dit, poster ici est une manière de se renseigner en lisant les remarques par exemple, non ?
Oui et non. Se renseigner, c'est poster « à quoi sert ce répertoire bizarre, /dev/shm, que j'ai sur mon système », pas écrire dedans comme ça sans réfléchir.
Herve Autret , dans le message <4ecd0390$0$681$426a74cc@news.free.fr>, a
écrit :
On peut aussi faire rm -Rf $HOME, si on veut.
La différence avec mon exemple, c'est que supprimer $HOME, on devine
immédiatement quel effet néfaste ça va avoir, alors que vire .Xauthority, un
fichier au nom abscons dont 99% des utilisateurs n'ont jamais entendu
parler, l'effet saute moins aux yeux.
Cette ressource n'est pas dissimulée
Il y a plein de choses dissimulées : essaie de passer /dev/mem en mode 0666
puis d'écrire dedans qu'on rigole.
(ce n'est pas comme si elle
s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de
raison de prendre des précautions quant à son emploi
Un jour, tu auras un problème avec un programme qui ne fonctionne pas sans
que tu saches pourquoi, et après avoir perdu des heures à chercher tu
comprendras pourquoi tu n'aurais pas dû toucher à /dev/shm.
Ceci étant dit, poster ici est une manière de se renseigner en lisant
les remarques par exemple, non ?
Oui et non. Se renseigner, c'est poster « à quoi sert ce répertoire bizarre,
/dev/shm, que j'ai sur mon système », pas écrire dedans comme ça sans
réfléchir.
Herve Autret , dans le message <4ecd0390$0$681$, a écrit :
On peut aussi faire rm -Rf $HOME, si on veut.
La différence avec mon exemple, c'est que supprimer $HOME, on devine immédiatement quel effet néfaste ça va avoir, alors que vire .Xauthority, un fichier au nom abscons dont 99% des utilisateurs n'ont jamais entendu parler, l'effet saute moins aux yeux.
Cette ressource n'est pas dissimulée
Il y a plein de choses dissimulées : essaie de passer /dev/mem en mode 0666 puis d'écrire dedans qu'on rigole.
(ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi
Un jour, tu auras un problème avec un programme qui ne fonctionne pas sans que tu saches pourquoi, et après avoir perdu des heures à chercher tu comprendras pourquoi tu n'aurais pas dû toucher à /dev/shm.
Ceci étant dit, poster ici est une manière de se renseigner en lisant les remarques par exemple, non ?
Oui et non. Se renseigner, c'est poster « à quoi sert ce répertoire bizarre, /dev/shm, que j'ai sur mon système », pas écrire dedans comme ça sans réfléchir.
Hugues
Ce cher Herve Autret a posté :
Cette ressource n'est pas dissimulée (ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à faire :-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Herve Autret <autret@lussinan.org> a posté :
Cette ressource n'est pas dissimulée (ce n'est pas comme si elle
s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de
raison de prendre des précautions quant à son emploi
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions
quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à
faire :-)
Cette ressource n'est pas dissimulée (ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à faire :-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Herve Autret
Hugues :
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à faire :-)
Là j'ai pas la casquette root ; j'essaie d'y penser quand c'est le cas. -- Hervé
Hugues :
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions
quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à
faire :-)
Là j'ai pas la casquette root ; j'essaie d'y penser quand c'est le cas.
--
Hervé
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à faire :-)
Là j'ai pas la casquette root ; j'essaie d'y penser quand c'est le cas. -- Hervé
NiKo
Le 23/11/2011 15:47, Nicolas George a écrit :
Herve Autret , dans le message <4ecd0390$0$681$, a écrit :
On peut aussi faire rm -Rf $HOME, si on veut.
La différence avec mon exemple, c'est que supprimer $HOME, on devine immédiatement quel effet néfaste ça va avoir, alors que vire .Xauthority, un fichier au nom abscons dont 99% des utilisateurs n'ont jamais entendu parler, l'effet saute moins aux yeux.
Cette ressource n'est pas dissimulée
Il y a plein de choses dissimulées : essaie de passer /dev/mem en mode 0666 puis d'écrire dedans qu'on rigole.
Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root, ce qui change tout au problème énoncé ici, puisque 'normalement' lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du système.
(ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi
Un jour, tu auras un problème avec un programme qui ne fonctionne pas sans que tu saches pourquoi, et après avoir perdu des heures à chercher tu comprendras pourquoi tu n'aurais pas dû toucher à /dev/shm.
Je stocke mon cache Firefox, mes répertoires .adobe et .macromedia et d'autres cochoncetés qui, de mon point de vue, n'ont pas à être persistants sur ma machine. Et je n'ai encore jamais vu de plantages, bugs où quoi que ce soit dans le style de ce que tu décris.
Et je te cite deux passages :
[...] If you compare it to ramfs (which was the template to create tmpfs) you gain swapping and limit checking. Another similar thing is the RAM disk (/dev/ram*), which simulates a fixed size hard disk in physical RAM, where you have to create an ordinary filesystem on top. Ramdisks cannot swap and you do not have the possibility to resize them. [...]
[...] 3) Some people (including me) find it very convenient to mount it e.g. on /tmp and /var/tmp and have a big swap partition. And now loop mounts of tmpfs files do work, so mkinitrd shipped by most distributions should succeed with a tmpfs /tmp. [...]
Tiré, tout de même, juste de la documentation du kernel.
Lorsqu'il compare /dev/shm et /dev/ram, il ne dit nulle part qu'il ne faut pas l'utiliser comme un système de fichiers ordinaire. Il dit plutôt que /dev/shm se comporte tout comme un /dev/ram, mais qu'il possède des avantages sur celui-ci (Imposition de limites, utilisation du swap en cas de besoin, inutilité de créer un système de fichiers).
Ceci étant dit, poster ici est une manière de se renseigner en lisant les remarques par exemple, non ?
Oui et non. Se renseigner, c'est poster « à quoi sert ce répertoire bizarre, /dev/shm, que j'ai sur mon système », pas écrire dedans comme ça sans réfléchir.
Je n'ai encore pas vu de distribution Linux où un utilisateur pouvait écrire dans un répertoire alors que, pour des raisons obscures que toi seul semble connaitre, il ne faudrait pas.
Tiens, je viens de faire :
$ dd if=/dev/zero of=/dev/shm/test dd: écriture vers «/dev/shm/test»: Aucun espace disponible sur le périphérique 8178537+0 enregistrements lus 8178536+0 enregistrements écrits 4187410432 octets (4,2 GB) copiés, 10,2424 s, 409 MB/s
puis :
$ dd if=/dev/zero of=/dev/shm/test2 dd: écriture vers «/dev/shm/test2»: Aucun espace disponible sur le périphérique 1+0 enregistrements lus 0+0 enregistrements écrits 0 octet (0 B) copié, 0,00106432 s, 0,0 kB/s
Bizarrement, tout fonctionne comme si je n'avais rien fait ! La seule différence se trouve dans le graphe d'utilisation de la RAM qui me montre que la moitié de celle ci est utilisée.
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Le 23/11/2011 15:47, Nicolas George a écrit :
Herve Autret , dans le message <4ecd0390$0$681$426a74cc@news.free.fr>, a
écrit :
On peut aussi faire rm -Rf $HOME, si on veut.
La différence avec mon exemple, c'est que supprimer $HOME, on devine
immédiatement quel effet néfaste ça va avoir, alors que vire .Xauthority, un
fichier au nom abscons dont 99% des utilisateurs n'ont jamais entendu
parler, l'effet saute moins aux yeux.
Cette ressource n'est pas dissimulée
Il y a plein de choses dissimulées : essaie de passer /dev/mem en mode 0666
puis d'écrire dedans qu'on rigole.
Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root,
ce qui change tout au problème énoncé ici, puisque 'normalement'
lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du
système.
(ce n'est pas comme si elle
s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de
raison de prendre des précautions quant à son emploi
Un jour, tu auras un problème avec un programme qui ne fonctionne pas sans
que tu saches pourquoi, et après avoir perdu des heures à chercher tu
comprendras pourquoi tu n'aurais pas dû toucher à /dev/shm.
Je stocke mon cache Firefox, mes répertoires .adobe et .macromedia et
d'autres cochoncetés qui, de mon point de vue, n'ont pas à être
persistants sur ma machine. Et je n'ai encore jamais vu de plantages,
bugs où quoi que ce soit dans le style de ce que tu décris.
Et je te cite deux passages :
[...] If you compare it to ramfs (which was the template to create
tmpfs) you gain swapping and limit checking. Another similar thing is
the RAM disk (/dev/ram*), which simulates a fixed size hard disk in
physical RAM, where you have to create an ordinary filesystem on top.
Ramdisks cannot swap and you do not have the possibility to resize them.
[...]
[...] 3) Some people (including me) find it very convenient to mount it
e.g. on /tmp and /var/tmp and have a big swap partition. And now loop
mounts of tmpfs files do work, so mkinitrd shipped by most distributions
should succeed with a tmpfs /tmp. [...]
Tiré, tout de même, juste de la documentation du kernel.
Lorsqu'il compare /dev/shm et /dev/ram, il ne dit nulle part qu'il ne
faut pas l'utiliser comme un système de fichiers ordinaire. Il dit
plutôt que /dev/shm se comporte tout comme un /dev/ram, mais qu'il
possède des avantages sur celui-ci (Imposition de limites, utilisation
du swap en cas de besoin, inutilité de créer un système de fichiers).
Ceci étant dit, poster ici est une manière de se renseigner en lisant
les remarques par exemple, non ?
Oui et non. Se renseigner, c'est poster « à quoi sert ce répertoire bizarre,
/dev/shm, que j'ai sur mon système », pas écrire dedans comme ça sans
réfléchir.
Je n'ai encore pas vu de distribution Linux où un utilisateur pouvait
écrire dans un répertoire alors que, pour des raisons obscures que toi
seul semble connaitre, il ne faudrait pas.
Tiens, je viens de faire :
$ dd if=/dev/zero of=/dev/shm/test
dd: écriture vers «/dev/shm/test»: Aucun espace disponible sur le
périphérique
8178537+0 enregistrements lus
8178536+0 enregistrements écrits
4187410432 octets (4,2 GB) copiés, 10,2424 s, 409 MB/s
puis :
$ dd if=/dev/zero of=/dev/shm/test2
dd: écriture vers «/dev/shm/test2»: Aucun espace disponible sur le
périphérique
1+0 enregistrements lus
0+0 enregistrements écrits
0 octet (0 B) copié, 0,00106432 s, 0,0 kB/s
Bizarrement, tout fonctionne comme si je n'avais rien fait ! La seule
différence se trouve dans le graphe d'utilisation de la RAM qui me
montre que la moitié de celle ci est utilisée.
--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !
SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !
Herve Autret , dans le message <4ecd0390$0$681$, a écrit :
On peut aussi faire rm -Rf $HOME, si on veut.
La différence avec mon exemple, c'est que supprimer $HOME, on devine immédiatement quel effet néfaste ça va avoir, alors que vire .Xauthority, un fichier au nom abscons dont 99% des utilisateurs n'ont jamais entendu parler, l'effet saute moins aux yeux.
Cette ressource n'est pas dissimulée
Il y a plein de choses dissimulées : essaie de passer /dev/mem en mode 0666 puis d'écrire dedans qu'on rigole.
Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root, ce qui change tout au problème énoncé ici, puisque 'normalement' lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du système.
(ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi
Un jour, tu auras un problème avec un programme qui ne fonctionne pas sans que tu saches pourquoi, et après avoir perdu des heures à chercher tu comprendras pourquoi tu n'aurais pas dû toucher à /dev/shm.
Je stocke mon cache Firefox, mes répertoires .adobe et .macromedia et d'autres cochoncetés qui, de mon point de vue, n'ont pas à être persistants sur ma machine. Et je n'ai encore jamais vu de plantages, bugs où quoi que ce soit dans le style de ce que tu décris.
Et je te cite deux passages :
[...] If you compare it to ramfs (which was the template to create tmpfs) you gain swapping and limit checking. Another similar thing is the RAM disk (/dev/ram*), which simulates a fixed size hard disk in physical RAM, where you have to create an ordinary filesystem on top. Ramdisks cannot swap and you do not have the possibility to resize them. [...]
[...] 3) Some people (including me) find it very convenient to mount it e.g. on /tmp and /var/tmp and have a big swap partition. And now loop mounts of tmpfs files do work, so mkinitrd shipped by most distributions should succeed with a tmpfs /tmp. [...]
Tiré, tout de même, juste de la documentation du kernel.
Lorsqu'il compare /dev/shm et /dev/ram, il ne dit nulle part qu'il ne faut pas l'utiliser comme un système de fichiers ordinaire. Il dit plutôt que /dev/shm se comporte tout comme un /dev/ram, mais qu'il possède des avantages sur celui-ci (Imposition de limites, utilisation du swap en cas de besoin, inutilité de créer un système de fichiers).
Ceci étant dit, poster ici est une manière de se renseigner en lisant les remarques par exemple, non ?
Oui et non. Se renseigner, c'est poster « à quoi sert ce répertoire bizarre, /dev/shm, que j'ai sur mon système », pas écrire dedans comme ça sans réfléchir.
Je n'ai encore pas vu de distribution Linux où un utilisateur pouvait écrire dans un répertoire alors que, pour des raisons obscures que toi seul semble connaitre, il ne faudrait pas.
Tiens, je viens de faire :
$ dd if=/dev/zero of=/dev/shm/test dd: écriture vers «/dev/shm/test»: Aucun espace disponible sur le périphérique 8178537+0 enregistrements lus 8178536+0 enregistrements écrits 4187410432 octets (4,2 GB) copiés, 10,2424 s, 409 MB/s
puis :
$ dd if=/dev/zero of=/dev/shm/test2 dd: écriture vers «/dev/shm/test2»: Aucun espace disponible sur le périphérique 1+0 enregistrements lus 0+0 enregistrements écrits 0 octet (0 B) copié, 0,00106432 s, 0,0 kB/s
Bizarrement, tout fonctionne comme si je n'avais rien fait ! La seule différence se trouve dans le graphe d'utilisation de la RAM qui me montre que la moitié de celle ci est utilisée.
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
