On 20120329_095413, Andrei POPESCU wrote: > On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote: > > > > > > 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. > > You must be misunderstanding me, I meant "some directory in your home", > because on most systems /home has enough space. > > > 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. > > Err... your original /tmp is a directory on / not a file[1] and if you > don't mount anything there your system will happily use the available > space on / (the root partition). > > [1] unless you had a dedicated partition, but AFAIK in such a case you > wouldn't get a tmpfs anyway > > > 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? > > Why do you think such scratch space should be in /tmp (regardless of > whether /tmp is on tmpfs, a separate partition or just a directory on > /)?
Why? Because the last time I looked which was long ago, using /tmp for scratch space was recommended practice in the FHS. I didn't decide to use /tmp when I started using it. /tmp was used by Debian packages and I used the packages. Then I read the FHS to try to understand how they managed to just do something that I well knew required scratch space. And there it was. Maybe not a requirement, but an indication that this was a useful result of coding to the standard. I question whether any debian package manager has ever released a package to testing without first doing some tests to be sure it used /tmp in a reasonable fashion. Whenever a software item arrived for packaging, my understanding is, that the bulk of the work of packaging is bringing it into compliance with FHS. As a consequence, I have very little patience with the argument that developers would sudden lose all self control and good sense merely because they have this new feature called tmpfs or ramfs. There is no record of them having been, as a group, so foolish. Also, today I am having an experience which seems to indicate that approx, the debian repository cacher, also has used /tmp for scratch files. In fact, after several hours of poking at it, I have abandoned use of approx for the while until this whole thing is sorted out by people who actually understand how Debian works, which is a small group of experts to which I surely don't deserve to belong. Kind regards, -- Paul E Condon pecon...@mesanetworks.net -- 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/20120330040200.gb14...@big.lan.gnu