C'est prévu pour Fedora 18 : http://fedoraproject.org/wiki/Features/tmp-on-tmpfs

Notons que certain demande à ce que la Feature soit révisée: https://fedorahosted.org/fesco/ticket/940

Je partage tout à fait la principale objection à mon sens pour ne pas monter /tmp en ram:

I also prefer that /tmp not be cleaned just because my machine unexpectedly rebooted. Just because a file is "temporary" does not mean it is unimportant, or that re-procuring it would be easy.

Sinon l'article est d'un grand intérêt et sans pitié pour cette fonctionnalité.

Je pense aussi que cette fonctionnalité devrait n'être proposée qu'en option, la valeur par défaut devant rester le tmp actuel.

Pour donner un exemple, il y a quelque jours, j'ai compilé plusieurs fois un programme de jeu, sans redémarrer, et je me suis retrouvé avec un tmp de 8 Go (essentiellement des fichier tmp regroupant les maps du jeu...).

Sachant que je n'ai que 6 Go de ram (ce qui est quand même important), que ce serait-il passé si tmp avait été monté en RAM ?

chepioq wrote:Sachant que je n'ai que 6 Go de ram (ce qui est quand même important), que ce serait-il passé si tmp avait été monté en RAM ?

Logiquement ta ram se serait délestée sur la swap. Donc quitte à faire de l'écriture disque, autant laisser /tmp dans son volume logique ou dans la racine...

nouvo09 wrote:Je partage tout à fait la principale objection à mon sens pour ne pas monter /tmp en ram:

I also prefer that /tmp not be cleaned just because my machine unexpectedly rebooted. Just because a file is "temporary" does not mean it is unimportant, or that re-procuring it would be easy.

Sinon l'article est d'un grand intérêt et sans pitié pour cette fonctionnalité.

Pourtant le FHS stipule :

/tmp : Temporary files
The /tmp directory must be made available for programs that require temporary files.
Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.
Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.
FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.

et

/var/tmp : Temporary files preserved between system reboots
The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp.
Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.

De mon point de vue, si la persistance d'un fichier est nécessaire au-delà du temps d'exécution d'un programme, /tmp n'est déjà pas le répertoire approprié. Il est peut-être couramment utilisé comme un répertoire fourre-tout, mais au-delà de ce qui est prévu par le standard bien souvent.

C@sp€r wrote:

chepioq wrote:Sachant que je n'ai que 6 Go de ram (ce qui est quand même important), que ce serait-il passé si tmp avait été monté en RAM ?

Logiquement ta ram se serait délestée sur la swap. Donc quitte à faire de l'écriture disque, autant laisser /tmp dans son volume logique ou dans la racine...

Pas d'accord. Ce que l'on peut clairement dire dans ce cas de figure est qu'il n'est pas forcément intéressant de passer par un tmpfs pour des questions de performance (ou parce que cela oblige à surdimensionner inutilement la partition de swap pour la même utilisation du même programme). Et que perdre 8Go de data avec un reboot, intempestif ou pas, peut donner envie de s'arracher les cheveux...

Donc que pouvoir définir un autre $TMPDIR (pas forcément celui hard-codé par le programme) devient très judicieux à ce moment. :-D

CanalGuada wrote: Donc que pouvoir définir un autre $TMPDIR (pas forcément celui hard-codé par le programme) devient très judicieux à ce moment. :-D

Certes mais il ne t'aura pas échappé ce que précise l'article, à savoir que beaucoup de programmes n'utilisent pas la variable $TMPDIR, mais le codent en dur.

Mauvaise habitude peut-être, mais il convient d'être pragmatique et réaliste.

nouvo09 wrote: Certes mais il ne t'aura pas échappé ce que précise l'article, à savoir que beaucoup de programmes n'utilisent pas la variable $TMPDIR, mais le codent en dur.

Mauvaise habitude peut-être, mais il convient d'être pragmatique et réaliste.

Il est aussi possible de prendre le problème dans l'autre sens, quitte à être pragmatique et réaliste... :-D Et considérer que c'est parce que les programmes ne respectent pas ce qui ressemble très fortement à un standard pourtant (et l'est concrètement dans le monde UNIX si je ne me trompe pas) que l'utilisateur et/ou le système ne peut pas librement maîtriser où vont se placer certains fichiers temporaires, alors que le FHS fournit déjà deux emplacements au choix.

Et dans ce cas, tenter d'être pro-actif en ne justifiant pas ce statu quo quand bien même tout le monde s'en soit accommodé jusqu'à présent, prétextant d'un "because that's the way it has worked for 40 years" alors que cela ne semble pas être le cas, la prise en compte de la variable d'environnement $TMPDIR faisant déjà partie de la spécification POSIX depuis quelques années.

Le FHS stipule que /tmp est un répertoire qui doit être laissé à la disposition des programmes, pas celui que doivent imposer les programmes à l'administrateur du système (considérant, de plus, qu'il fournisse plus de persistance que prévu initialement).

Pour ma part, je n'ai aucun doute sur le fait que ce soit une mauvaise habitude, à corriger d'autant plus vite qu'elle devient inutilement bloquante pour d'autres développements. D'autant plus qu'un correctif dans ce sens ne m'apparaît pas être d'une grande complexité à mettre en place avec un peu de temps et de bonne volonté...