Re: /tmp as tmpfs and consequence for imaging software
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 at
runelevel 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 <firstname.lastname@example.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 !
Goswin von Brederlow wrote:File: /usr/share/initscripts/default.rcS
Roger Leigh <email@example.com> 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
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.