Re: how to increase space for tmpfs /tmp
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.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: