On Fri, 22 Jun 2012, Andrei POPESCU wrote: > On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote: > > Fine let’s talk. Why can’t we find a compromise? Additional to our > > disk /tmp we create a /ramtmp (so the name suggests that this tmp is > > a ramdisk) with tmpfs. This should be doable in time for Wheezy. The > > release notes should mention it. And those who wish can patch their > > programs to use the ramdisk if they think their program uses only > > small temporary files. In this way, we get some data and experience. > > And we have both worlds. /tmp on disk for even large temporary files > > and /ramtmp as fast ramdisk. > > Why not use /run instead?
Feel free to add a *mountpoint* at /run/tmp and provide a second tmpfs there[1]. But if you do that, we'd have /tmp, /run/tmp, and /var/tmp so to me it just looks like a mess... Well, /var/tmp is always disk-backed and it is supposed to last across reboots, and files there should last for a while before any automated cleaning. It is written nowhere that you can leave large files in there, though, but it is not supposed to be too space-constrained. /run/tmp might be defined from the get go to be tmpfs, and not some place you should expect to be able to abuse (i.e. can't be automatically used to unpack large amounts of crap, host the tile cache of a pixel editor or the browser's cache, etc). What good would it do, I don't know: you'd need to set TMPDIR=/run/tmp to use it anyway, so might as well just do it to /tmp... [1] Should you fill /run or cause a filename colision, very bad things can happen. You don't use /var/lock and /var/run as a general dumping ground for random crap, and the same rule applies to /run. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120622192819.gc32...@khazad-dum.debian.net