[Roger Leigh] > These two filesystems serve fundamentally different purposes, and > namespace collisions between those two uses should be avoided at all > costs -- by keeping them completely separate.
Perhaps. /dev/shm/ is well defined and out of scope for how dosemu and user-mode-linux uses it, while /etc/init/rw/ is new and can be used for what we decide to use it for. :) > Is there any good reason to combine the two? The reason I see is to limit the amount of mounted tmpfs partitions to one, to reduce the risk of spending all of memory on them. :) > Please don't do this. Sensible defaults are all that is required in > both cases. For /lib/init/rw, this could most likely be set to a > tiny amount, like the 100 KiB suggested. For /dev/shm, requirements > could be a lot higher, and vary from system to system, but again a > sensible default would fix this. Why should /dev/shm/ be so high? There are almost no application using the shm*() functions in glibc. Which one of these need a large file? > The current practice of using the kernel default of 0.5*coresize is > wrong. I'm currently safe, having a good 6 GiB of swap, but for high > memory systems with less swap than core, you're heading into potential > DoS territory with the current approach. On a system with 8 GiB of > core, a 4 GiB /lib/init/rw is a waste and a huge liability. I believed unused tmpfs space wasn't taking up any space in the kernel. Is this not so? > Suggestion: choose fixed limits, and allow the user to configure both. > /lib/init/rw could be fixed to a specific size, and /dev/shm could be > e.g. 0.5*core up to an upper limit of 512 MiB (by default). > > The current SHM_SIZE in /etc/default/tmpfs is no longer sufficient. > Please could you add an INIT_RW_SIZE in addition, and set it > by default? (As in the patch). There is a variable RW_SIZE allowing you to set the size of /lib/init/rw/. It was introduced in version 2.86.ds1-24. > Also, given the widely differing sizes of the various tmpfs > filesystems, TMPFS_SIZE is not really all that useful any more. > Could this be deprecated or removed? Well, it is not obvious to me that the various tmpfs file systems do have widely different size requirements, so I do not plan to deprecate it myself. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]