On Thu, 22 Dec 2005, Russell Coker wrote: > On Monday 19 December 2005 23:04, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote: > > > tmpfs stores run ressources in vm more efficiently (since they are > > > otherwise in th buffercache and the filesystem). > > > > Quite the contrary. tmpfs needs vm space even if nobody needs the data > > (thus, it could be evicted from the page cache if it were on a > > disk-backed fs). > > Whether it's on ext3 or tmpfs the end result is that it's in RAM if it's > being > used and on disk if it hasn't been used for a while. The only difference is > whether "on disk" means a swap partition or an ext3 file system.
That was my knee-jerk reaction too, but there IS indeed a difference. With ext3 (or a non-VM-based fs), you can drop almost all data which is in memory (which uses *no* resources once dropped), and the amount of data you have to retain is not linearly coupled to the filesystem size. On a vm-based fs, you always use *address space* for data in it, and it is linearly coupled to the amount of filesystem used (or even to the full size, for extremely dumb filesystems). Not that address space shortage is something I'd fear in the machines we have today because of a < 5MiB tmpfs, and I am not even talking of a 64-bit box. Someone who has such shortage won't have it any worse because of a small tmpfs, and the fix will still be to move to a 64-bit platform. So the whole "eats vm-space" argument against /run (or /var/run, /lib/run, /.313373/d3b14n.ru135 or whatever it ends up being named) in tmpfs is just noise IMHO. -- "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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
