I find it hard to believe the origional bug is #630615 based on people's comments! That's Funny! 1) rc.boot is for booting not for demanding / depends on kernel Options so and so opted in (ie, tmpfs). (is that why I had to hack mknod ptys in rc.local on one pc? wtf?) Please do extras atrunelevel 2 or 3 - there's no reason to allow processes to share memory before multi-user logins that I've heard of! i'm unsure I'd allow it?
2) why is any init file in /usr/share? what makes anyone think it's mountable if booting a root slice single-user mode to fix other partitions/mounts? init scripts are [were] on the root disk for a reason :) ie, File: /usr/share/initscripts/default.rcS 3) Whether 1.2G is or is not in a directory is a mute Question and argument. /tmp is purely a convention of convenience and not construed to be memory share system or not, never was, you'll break allot of things if you try imposing new rules to "help out" new software do some deed it claims it needs that infact it can do without /tmp in the first place. While amazon.com "cloud" may have small RAM and large disks, many mainframes are opposite (ie, IBM big blue, japan's world simulator). And many new PCs may become that way: no spin :) Maybe not! cat /usr/src/linux | grep -i "tmpfs" # CONFIG_DEVTMPFS is not set # CONFIG_TMPFS_XATTR is not set shared mem is good but ads a few bads. It's an option for a reason. Michael Biebl <biebl@debian.org> v. debian-bugs, I confirmed it's a bug :) Cheers to Michael, cheers to all ! And may debian gets lots of orders at Christmas ! John Goswin von Brederlow wrote:File: /usr/share/initscripts/default.rcS
Roger Leigh <rleigh@codelibre.net> writes:On Sat, Nov 12, 2011 at 10:24:00PM +0100, Bastien ROUCARIES wrote:Recently debian put /tmp under tmpfs. Even if it increase reponsivness under desktop, it ruin completly sciene and imaging software that do some off loading on /tmp. For instance using gscan2pdf on 60pages document create more than 1.2G of image file under /tmp and crash du to missing space. What are the solution for this kind of problem ?As mentioned elsewhere in this thread, this is discussed in detail in #630615. As touched on in the bug report, I think that being able to store 1.2GiB on /tmp is an unrealistic expectation. To qualify, I mean to expect that to work *by default*. If you want to store such large amounts of data, you will need to configure your system to handle that, either by: - provisioning of more swap and raising of the TMP_SIZE limit. - disabling RAMTMP and using a disc-backed filesystem (either the rootfs or dedicated /tmp mount). Again, as mentioned in the report, due to the wide variation in disc partitioning, filesystem utilisation and RAM capacity between systems, we don't currently make *any* guarantees regarding a minimum amount of space available in /tmp, when using a disc-backed /tmp. If the rootfs fills up, /tmp will cease to allow creation of new files. When using tmpfs, we do at least make a minimum guarantee of having a certain amount of storage available (which might albeit be used by other users).Correct me if I'm wrong but doesn't having a real filesystem for /tmp in /etc/fstab prevent tmpfs from being mounted there? And wouldn't everyone expecting to frequently store 1.2GB files in /tmp create such a filesystem during installation? Having /tmp on / would quickly degrade performance as the filesystems free space becomes fragmented over time. So if you end up with a tmpfs for /tmp on such a system you already did install your systems wrong for your use case under the old setup. So only suboptimal configurations are hurt by defaulting to tmpfs. :)I'm not sure that I can really add more at this point than which was already included in the bug report. As a general rule, I think it's fair to say that if you want to *guarantee* the availability of that much storage, the defaults will not typically be sufficient.a But the defaults are just defaults--you are free to configure your system to satisfy your needs as you see fit. Regards, RogerMfG Goswin