On Wed, Mar 28, 2012 at 6:58 PM, Paul E Condon <pecon...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SyhbUEwdT8cS4JXUgj30KCyzHoZP5M6yWOVO-NH_=w...@mail.gmail.com
