* Daniel Kahn Gillmor <[EMAIL PROTECTED]> [2008-11-08 19:58-0500]: > Hi Micah-- > > Thanks for adjusting the default vserver device tree to include > /dev/shm!
Hey, thanks for noticing it and reporting it, I'm going to request that it receive a release exception so it can be included in Lenny, it seems worthy considering its POSIX compliance. Upstream is likely to commit the change as well. > On Sat 2008-11-08 14:07:20 -0500, Micah Anderson wrote: > > > I think its probably best to leave it as a regular directory, rather > > than a tmpfs. The reason is because we already are providing a very > > minimal /tmp as a tmpfs, and this eats into the available memory on the > > entire box (this of course can be increased as needed, but it occupies > > memory space), adding a second tmpfs that must get mounted at /dev/shm > > will further complicate this resource problem. I think that the best way > > to handle it is to leave it as a directory, and let the admin decide if > > they want to remount it as a tmpfs for optimization purposes and based > > on their particular host's memory availability. > > It was my impression that a tmpfs only consumes RAM when there is data > in it; for example, you can allocate a very large tmpfs with no > increase in memory consumption: Yes, that is true in vservers as well. > And surely there are other ways that a guest vserver can also consume > RAM aside from a tmpfs, like a memory-hungry process! Certainly, however there are resource limits that you can impose on processes. > Is it that the RAM in a tmpfs is by definition outside of the vserver > framework's ability to limit RAM consumption? If so, why is /tmp set > up that way at all, when it does not need to be? Why not default to > no tmpfs mounts? To my mind, there is a better argument for /dev/shm > to be a tmpfs than there is for /tmp, since it is required for POSIX > shared memory compatibility, but i am probably missing the bigger > picture. > > I'm not sure i understand the rationale behind the decision of when to > ship a tmpfs by default and when not to. Can you explain? The preference as to why it is preferable to keep it as a directory over a tmpfs is essentially related to the resources and what mechanisms are available for limiting them. As I understand it, applications that do use /dev/shm will want to use large segments and by default adding something that enables large amounts of easily consumable memory/swap space that is outside of the available vserver memory limiting capabilities is not a good idea for a default, especially when the option of setting it yourself when you are needing to is available. As I understand it, usage of /dev/shm is not particularly common, it has not existed by default in vserver guests ever, and you are the first person to notice it (and these utilities have existed for I think somewhere around 5 years now)... I am not aware of any commonly-used software that uses it, That doesn't mean that the usage might be increasing, or there aren't valid use-cases for it, but upstream's position is that they will consider adding it to the default fstab when some commonly used piece of software uses it, and until then people who actually require it can add it themselves. Micah
signature.asc
Description: Digital signature
