Re: how to increase space for tmpfs /tmp
On Fri, Mar 30, 2012 at 4:12 PM, Paul E Condon
<pecondon@mesanetworks.net> wrote:
> On 20120330_030935, Tom H wrote:
>> On Wed, Mar 28, 2012 at 6:58 PM, Paul E Condon
>> <pecondon@mesanetworks.net> wrote:
>> > On 20120329_011019, Andrei POPESCU wrote:
>> >> On Mi, 28 mar 12, 20:47:45, Camaleón wrote:
>> >> > On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:
>> >> > > On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
>> >> >
>> >> > >> > but the short version would be "You can't make an omelette without
>> >> > >> > breaking eggs"
>> >> > >>
>> >> > >> Which explains little about your arguments (that's a general stanza)
>> >> > >> >:-)
>> >> > >
>> >> > > Well, so is yours, unless we are talking past each other. I was
>> >> > > specifically addressing only that paragraph, out of context.
>> >> >
>> >> > I didn't know you were interested in my arguments... they can be read
>> >> > here:
>> >> >
>> >> > http://lists.debian.org/debian-user/2011/11/msg02155.html
>> >> > http://lists.debian.org/debian-user/2011/11/msg02207.html
>> >> > http://lists.debian.org/debian-user/2012/03/msg00280.html
>> >>
>> >> We are still talking past each other on this one. Let me try again[1]: I
>> >> was only disagreeing with you on the rather general statement that
>> >> defaults should not change when they create problems for users. Nothing
>> >> more.
>> >>
>> >> [1] but I won't be posting anymore on this, it's OT already
>> >>
>> >> > > It seems to me you are expecting specific arguments about the /tmp on
>> >> > > tmpfs issue. As far as I recall you did read through the debian-devel
>> >> > > discussion(s), what point is there for me to repeat it here (even if my
>> >> > > memory is faulty and you did not read it)?
>> >> >
>> >> > I read the thread it was mentioned when I first asked for feedback, which
>> >> > was this:
>> >> >
>> >> > http://lists.debian.org/debian-devel/2011/11/threads.html#00281
>> >> >
>> >> > But to be sincere, I don't remember "all" of the contents of the posts
>> >> > nor "who" posted there "what"... and now you tell, I can't see any post
>> >> > belonging to you in that thread. Maybe you made your comments afterwards?
>> >>
>> >> I most probably didn't contribute at all. What for? People more
>> >> knowledgeable than me and with more real life experience were already
>> >> debating the issue with interesting arguments for both "sides".
>> >>
>> >> > > You expected to be able to uncompress an archive of unspecified size to
>> >> > > /tmp on a testing system.
>> >> >
>> >> > "Unspecified size"?
>> >>
>> >> If you did mention a size I must have missed it, sorry for that.
>> >>
>> >> > It was just the kernel source (75 MiB). Wow. How. Big. >:-)
>> >>
>> >> Since this created problems for you I'm assuming either a small amount
>> >> of RAM (less than 512 MB?[2]) which points to a lower spec machine that
>> >> would need special care anyway, or that something else was already
>> >> hogging /tmp (which kinda' proves Roger's point).
>> >>
>> >> [2] 20% of 512 MB is still aprox. 100MB. My laptop is up 2 days and I'am
>> >> running iceweasel, xxxterm, libreoffice, aptitude, mutt, pidgin, but
>> >> /tmp usage is still below 1MB (844 KB according to 'df -h').
>> >>
>> >> > > 1. you may have had similar issues uncompressing that on any other
>> >> > > filesystem (small partition, quota, etc.)
>> >> >
>> >> > I doubt it becasue I tend to put special care for that can't happen (my netbook
>> >> > has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and "/" (the
>> >> > remaining space). Since I returned "/tmp" to the root filesystem I've had no
>> >> > more "hiccups".
>> >>
>> >> You could have also considered uncompressing the tarball somewhere else,
>> >> like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially
>> > ^^^^^^^^^ ^^^^^^^^^
>> >
>> > On my computer that is running wheezy neither of these suggestions work,
>> > because, I think, these are not mount points supporting access to external
>> > physical disk hardware. I tested this suggestion this morning. I don't
>> > fully understand this, but I have been told that access to the original
>> > /tmp file requires an entry in /etc/fstab. Think about it. Who is supplying
>> > this extra hardware? Any specialized software that requires scratch files
>> > because the work is too large to fit in ram is dead in the water with this
>> > change, and changing the setting of RAMTMP does not fix the problem, or
>> > any of the work-arounds that have been suggested so far. I think this is
>> > a serious flaw in the current wheezy, a release critical flaw perhaps.
>> >
>> > My particular problem is a project in which I regularly need to sort
>> > files 2 to 3 GB in size on a computer with less than 1 GB of ram and
>> > 370 GB of rotating disk. But I am sure there are other problems
>> > needing real, physical scratch space running very nicely on computers
>> > old enough to have once run woody. And now they are to be broken by
>> > something in wheezy software? Can this happen? Really?
>>
>> I understand Andrei's suggestion to be that you set TMPDIR to a
>> directory in home when launching the particular job that needs a large
>> TMPDIR.
>>
>> Someone pointed out, in this thread or another tmpfs one, that the
>> limit for the tmpfs size of "/tmp" is "RAM+SWAP" so you could increase
>> the size of your swap to accommodate your sort - or simply disable
>> tmpfs for "/tmp" on this box.
>
> It is my understanding that the directory that one wishes to use in
> TMPDIR must be mentioned in a line in /etc/fstab for this to work, and
> a block special mountable device must be mentioned in that line. And
> this is the way it does work on my system. Choise of TMPDIR did not
> have this restriction in the past. This change has implications for
> many packages. My point is that competent developers should check this
> out. I have found a way forward on my personal situation without
> pressing this discussion further. Your suggestion is not useful for
> addressing the problem that I was trying to describe. If I am wrong,
> my bad. But if this is true, there will be a lot of pain and anguish.
>
> Enough said. Thankyou.
Not quite!
To expand on what I think was Andrei's suggestion, you can run mc, for
example, this way "TMPDIR=/home/user/tmp mc"; mc will create tmp files
in "/home/user/tmp" as long as "/home/user/tmp" exists.
Two other solutions are to use the "RAM+SWAP" method mentioned above
or to revert back to the previous behavior of "/tmp" by disabling the
use of tmpfs for it with "RAMTMP=no" in "/etc/default/rcS" and either
allowing "/tmp" to be on "/" or create a separate partition for it and
mount it via "/etc/fstab".
With "My point is that competent developers should check this out"
you're implying that the person who made this change isn't competent;
not a particularly useful, helpful, or kind thing to say...
Reply to: