Re: how to increase space for tmpfs /tmp
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.
Reply to: