On Fri, Mar 30, 2012 at 4:12 PM, Paul E Condon <pecon...@mesanetworks.net> wrote: > On 20120330_030935, Tom H wrote: >> 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. > > 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... -- 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=Sx=sk4i8pue_beefjzrgakvqksd1jhfvj0mnwwxr4a...@mail.gmail.com
