May I suggest the following command in order to see where files may be hidden?
du -hx --max-depth=1 / | sort -h
It may take a longer time to complete. It only examines the root partition.
It should also show hidden disk usage in case something is mounted on a
directory with files in it.
The
On 07/04/12 10:57, Scott Ferguson wrote:
On 07/04/12 09:14, Bob Proulx wrote:
Scott Ferguson wrote:
Bob Proulx wrote:
but, but, but I was told Big Data is the Big Thing
I know you are just teasing
With teeth bared. snipped
Whoops - sooorry. Too much chocolate! :-(
Just forget you
Scott Ferguson wrote:
Bob Proulx wrote:
but, but, but I was told Big Data is the Big Thing
I know you are just teasing but on a serious note I am really hoping
good things come from the Freedom Box project. It addresses the
problems with the current implementations of cloud computing.
On 07/04/12 09:14, Bob Proulx wrote:
Scott Ferguson wrote:
Bob Proulx wrote:
but, but, but I was told Big Data is the Big Thing
I know you are just teasing
With teeth bared. Cloud is good for a number of things. Cloud is not
good for most of the things it's being used and promoted for.
Scott Ferguson wrote:
Bob Proulx wrote:
Scott Ferguson wrote:
Martin Steigerwald wrote:
I like the notion to just use /var/tmp for anything big by default.
Doesn't that require manually deleting files when they're no longer
required?
Of course that is no different from /tmp which
On 06/04/12 05:39, Bob Proulx wrote:
Scott Ferguson wrote:
Bob Proulx wrote:
Scott Ferguson wrote:
Martin Steigerwald wrote:
I like the notion to just use /var/tmp for anything big by default.
Doesn't that require manually deleting files when they're no longer
required?
Of course that is
On Ma, 03 apr 12, 10:13:48, Roger Leigh wrote:
On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
I'd try bringing the system up in recovery mode, unmount all ext3
file systems (except /, obviously) and run the du command again. You
might find data that was concealed under the mount
On Wed, Apr 04, 2012 at 11:25:40AM +0300, Andrei POPESCU wrote:
On Ma, 03 apr 12, 10:13:48, Roger Leigh wrote:
On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
I'd try bringing the system up in recovery mode, unmount all ext3
file systems (except /, obviously) and run the du command
On Mi, 04 apr 12, 09:38:44, Roger Leigh wrote:
It would normally be cleaned on boot anyway, so I think we can
avoid putting this in the Release Notes if we clean it automatically.
Isn't this dangerous? (It's unclear to me if /tmp is cleaned in squeeze
by default or not)
I'm thinking it
On Wed, Apr 04, 2012 at 12:14:43PM +0300, Andrei POPESCU wrote:
On Mi, 04 apr 12, 09:38:44, Roger Leigh wrote:
It would normally be cleaned on boot anyway, so I think we can
avoid putting this in the Release Notes if we clean it automatically.
Isn't this dangerous? (It's unclear to me
Am Donnerstag, 29. März 2012 schrieb Javier Vasquez:
So yes, one needs to be careful, not to oversize your tmpfs. That's
completely true, but the limit is not physical RAM, it is actually
RAM+Swap, as I mentioned before.
On this thread, it is asked about how to got with huge files to be
Am Dienstag, 3. April 2012 schrieb Roger Leigh:
On Tue, Apr 03, 2012 at 11:16:08AM +0200, Vincent Lefevre wrote:
On 2012-03-24 11:00:49 -0600, Javier Vasquez wrote:
You can always configure as you wish. Take a look at:
/etc/default/tmpfs
The file says:
# NOTE: This file is
Am Dienstag, 3. April 2012 schrieb Roger Leigh:
On Sat, Mar 24, 2012 at 06:00:23PM -0300, Henrique de Moraes Holschuh
wrote:
On Sat, 24 Mar 2012, Joey Hess wrote:
Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to
point to something like $HOME/tmp
You don't need to
On 05/04/12 04:38, Martin Steigerwald wrote:
Am Dienstag, 3. April 2012 schrieb Roger Leigh:
On Sat, Mar 24, 2012 at 06:00:23PM -0300, Henrique de Moraes Holschuh
wrote:
On Sat, 24 Mar 2012, Joey Hess wrote:
Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to
point to something
Scott Ferguson wrote:
Martin Steigerwald wrote:
I like the notion to just use /var/tmp for anything big by default.
Doesn't that require manually deleting files when they're no longer
required?
Of course that is no different from /tmp which is the same until
rebooted and I only reboot for
On 05/04/12 11:41, Bob Proulx wrote:
Scott Ferguson wrote:
Martin Steigerwald wrote:
I like the notion to just use /var/tmp for anything big by default.
Doesn't that require manually deleting files when they're no longer
required?
Of course that is no different from /tmp which is the same
On 20120402_234538, Stan Hoeppner wrote:
On 4/2/2012 9:43 PM, Paul E Condon wrote:
This is the du command and results:
root@gq:/# du -k -s -c /[^pm]* /m[^e]*
4 /home
Is your /home empty? Your du command seems to think so. That's hard to
Yes. It was empty at the time at which the
On 03/04/12 09:08, Paul E Condon wrote:
On 20120402_234538, Stan Hoeppner wrote:
On 4/2/2012 9:43 PM, Paul E Condon wrote:
This is the du command and results:
root@gq:/# du -k -s -c /[^pm]* /m[^e]*
4 /home
Is your /home empty? Your du command seems to think so. That's hard to
On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
I'd try bringing the system up in recovery mode, unmount all ext3
file systems (except /, obviously) and run the du command again. You
might find data that was concealed under the mount points.
It's even possible that it's under /tmp.
--
On 2012-03-24 11:00:49 -0600, Javier Vasquez wrote:
You can always configure as you wish. Take a look at:
/etc/default/tmpfs
The file says:
# NOTE: This file is deprecated. Please see rcS(5) for details on how
# to configure tmpfs size limits.
--
Vincent Lefèvre vinc...@vinc17.net - Web:
On Tue, Apr 03, 2012 at 11:16:08AM +0200, Vincent Lefevre wrote:
On 2012-03-24 11:00:49 -0600, Javier Vasquez wrote:
You can always configure as you wish. Take a look at:
/etc/default/tmpfs
The file says:
# NOTE: This file is deprecated. Please see rcS(5) for details on how
# to
On Sat, Mar 24, 2012 at 06:00:23PM -0300, Henrique de Moraes Holschuh wrote:
On Sat, 24 Mar 2012, Joey Hess wrote:
Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to point to
something like $HOME/tmp
You don't need to reboot because of the size change.
mount -o
On 2012-03-25 10:51:07 +, Camaleón wrote:
Sorry for not having attached the link, I was a bit hurry. Here it is:
http://lists.debian.org/debian-user/2011/11/msg02155.html
http://lists.debian.org/debian-user/2012/02/msg01614.html
http://lists.debian.org/debian-user/2012/03/msg00277.html
On 2012-03-27 14:13:23 +0100, Roger Leigh wrote:
A common (and very persuasive) argument for not mounting a tmpfs
on /tmp and instead using the root filesystem is that by default
we install with a single large root filesystem, and /tmp gets to
use all the free space there. This is certainly
On 2012-03-28 18:32:25 +0100, Roger Leigh wrote:
Applications should not be selfish, and should not blindly fill it.
Take the streaming media example from earlier today. Is it
appropriate to dump potentially limitless streams of data to /tmp?
/Obviously/, it's going to be filled to capacity
On 2012-03-28 19:12:27 +0100, Brian wrote:
But defaults are defaults. Files in /etc/default can be altered.
This is OK for system-wide settings, such as:
Do I really want portmap to listen on all interfaces? Do I want CUPS
to load a driver for a parallel port printer when I do not have one.
Hello Vincent,
Vincent Lefevre vinc...@vinc17.net wrote:
On 2012-03-28 18:32:25 +0100, Roger Leigh wrote:
FYI, Firefox/Iceweasel uses /tmp for that. For instance, click on
a link to a PDF file to view it with a PDF viewer; the file is
stored in /tmp. It isn't even removed after the
On 2012-04-03 13:54:55 +0200, Claudius Hubig wrote:
Vincent Lefevre vinc...@vinc17.net wrote:
On 2012-03-28 18:32:25 +0100, Roger Leigh wrote:
FYI, Firefox/Iceweasel uses /tmp for that. For instance, click on
a link to a PDF file to view it with a PDF viewer; the file is
stored in /tmp.
On Tue, 03 Apr 2012 12:31:57 +0200, Vincent Lefevre wrote:
On 2012-03-25 10:51:07 +, Camaleón wrote:
Sorry for not having attached the link, I was a bit hurry. Here it is:
http://lists.debian.org/debian-user/2011/11/msg02155.html
http://lists.debian.org/debian-user/2012/02/msg01614.html
On 20120403_101348, Roger Leigh wrote:
On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
I'd try bringing the system up in recovery mode, unmount all ext3
file systems (except /, obviously) and run the du command again. You
might find data that was concealed under the mount points.
On 4/3/2012 1:18 PM, Paul E Condon wrote:
3) Stan says that the disk is full and that du is just wrong.
That's not actually what I said. There is a subtle but distinct difference:
Me: Your du isn't reflecting reality of what's
on disk.
Your du implies both the exact command line w/switches
Paul E Condon wrote:
Roger Leigh wrote:
Dom wrote:
I'd try bringing the system up in recovery mode, unmount all ext3
file systems (except /, obviously) and run the du command again. You
might find data that was concealed under the mount points.
It's even possible that it's under
...@hardwarefreak.com
To: debian-user@lists.debian.org
Subject: Re: how to increase space for tmpfs /tmp
Date: Tue, 03 Apr 2012 13:34:46 -0500
On 4/3/2012 1:18 PM, Paul E Condon wrote:
3) Stan says that the disk is full and that du is just wrong.
That's not actually what I said. There is a subtle
On Ma, 03 apr 12, 12:31:57, Vincent Lefevre wrote:
Thanks, but not all users want to spend all their time reading long
threads. Shouldn't there be something in the Debian FAQ and/or wiki
(I couldn't find anything) in order to have a common resource for
such information?
I'm quite certain
On Sun, Apr 1, 2012 at 2:52 PM, Paul E Condon pecon...@mesanetworks.net wrote:
On 20120401_130449, Andrei POPESCU wrote:
On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
Having a tmpfs filesystem for /tmp doesn't mean that a dedicated
partition is required for /tmp.
What you say doesn't
On Fri, Mar 30, 2012 at 02:12:03PM -0600, Paul E Condon wrote:
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.
This understanding is
On 20120402_043958, Tom H wrote:
On Sun, Apr 1, 2012 at 2:52 PM, Paul E Condon pecon...@mesanetworks.net
wrote:
On 20120401_130449, Andrei POPESCU wrote:
On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
Having a tmpfs filesystem for /tmp doesn't mean that a dedicated
partition is
On 20120402_143034, Roger Leigh wrote:
On Fri, Mar 30, 2012 at 02:12:03PM -0600, Paul E Condon wrote:
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
On Mon, Apr 02, 2012 at 08:50:25AM -0600, Paul E Condon wrote:
On 20120402_143034, Roger Leigh wrote:
Other than defaulting to mounting a tmpfs on /tmp, there have been
*no other changes*!! I tend to suspect from this thread that the
problems you are experiencing are entirely
On Wed, 28 Mar 2012 16:58:03 -0600, Paul E Condon wrote:
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
On 20120402_165955, Roger Leigh wrote:
On Mon, Apr 02, 2012 at 08:50:25AM -0600, Paul E Condon wrote:
On 20120402_143034, Roger Leigh wrote:
Other than defaulting to mounting a tmpfs on /tmp, there have been
*no other changes*!! I tend to suspect from this thread that the
problems you
On Mon, Apr 02, 2012 at 11:55:02AM -0600, Paul E Condon wrote:
During my tests, I noticed that there was always a line in df,
concerning /tmp in tmpfs. With RAMTMP=yes the line was labeled tmpfs,
but with RAMTMP=no, the line was labeled 'overflow', or something else
that I misremember as
[hope you don't mind the CC, but I figured you don't follow debian-user
very closely]
On Lu, 02 apr 12, 21:56:20, Roger Leigh wrote:
Have a look at /etc/init.d/mountoverflowtmp.
Your root filesystem is full. This triggers the mounting of a
tmpfs on /tmp *irrespective* of the RAMTMP
On Tue, Apr 03, 2012 at 12:26:21AM +0300, Andrei POPESCU wrote:
[hope you don't mind the CC, but I figured you don't follow debian-user
very closely]
No worries, but I am a subscriber.
On Lu, 02 apr 12, 21:56:20, Roger Leigh wrote:
Have a look at /etc/init.d/mountoverflowtmp.
Your
On 20120402_215620, Roger Leigh wrote:
On Mon, Apr 02, 2012 at 11:55:02AM -0600, Paul E Condon wrote:
During my tests, I noticed that there was always a line in df,
concerning /tmp in tmpfs. With RAMTMP=yes the line was labeled tmpfs,
but with RAMTMP=no, the line was labeled 'overflow', or
On 4/2/2012 9:43 PM, Paul E Condon wrote:
This is the du command and results:
root@gq:/# du -k -s -c /[^pm]* /m[^e]*
4 /home
Is your /home empty? Your du command seems to think so. That's hard to
believe. It would mean you ever created any users. A newly created
empty dir has a size
On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
Having a tmpfs filesystem for /tmp doesn't mean that a dedicated
partition is required for /tmp.
What you say doesn't work for me, but something else does.
Show us (what doesn't work) :)
Kind regards,
Andrei
--
Offtopic discussions
On 20120401_130449, Andrei POPESCU wrote:
On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
Having a tmpfs filesystem for /tmp doesn't mean that a dedicated
partition is required for /tmp.
What you say doesn't work for me, but something else does.
Show us (what doesn't work) :)
On Vi, 30 mar 12, 16:40:18, Paul E Condon wrote:
Perhaps you are thinking of an officially published requirement. What
I mean 'requirement' is a condition which by trial is found to be
necessary for it to work. I tried cases that did not meet this
condition and none of them worked, and
On Fri, Mar 30, 2012 at 4:44 PM, Paul E Condon
pecon...@mesanetworks.net wrote:
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
On 20120331_114636, Andrei POPESCU wrote:
On Vi, 30 mar 12, 16:40:18, Paul E Condon wrote:
Perhaps you are thinking of an officially published requirement. What
I mean 'requirement' is a condition which by trial is found to be
necessary for it to work. I tried cases that did not meet
On 20120331_061146, Tom H wrote:
On Fri, Mar 30, 2012 at 4:44 PM, Paul E Condon
pecon...@mesanetworks.net wrote:
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,
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
On Jo, 29 mar 12, 22:02:00, Paul E Condon wrote:
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
On Fri, 30 Mar 2012 00:20:14 +0300, Andrei POPESCU wrote:
On Jo, 29 mar 12, 14:21:58, Camaleón wrote:
I don't usually pay much attention to what NEWS.Debian says
Do you have apt-listchanges installed? It's Priority: standard now.
For this system I don't know... going to check. Yes, it's
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,
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
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,
On 20120330_164907, Tom H wrote:
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
On Vi, 30 mar 12, 14:44:37, Paul E Condon wrote:
No. You misunderstand me. There is a new extra requirement on TMPDIR, a
restriction on ones choise of its value. A directory entry on a disk
file system is not enough. It must be a directory entry that has a line
in /etc/fstab that enables its
On 20120331_00, Andrei POPESCU wrote:
On Vi, 30 mar 12, 14:44:37, Paul E Condon wrote:
No. You misunderstand me. There is a new extra requirement on TMPDIR, a
restriction on ones choise of its value. A directory entry on a disk
file system is not enough. It must be a directory entry
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
On Thu, Mar 29, 2012 at 01:29:32AM +0200, Michael Biebl wrote:
On 28.03.2012 20:27, Dom wrote:
This change has caused me a number of (admittedly not too serious)
problems.
To get a better feeling for what kind of problems users with
tmpfs-on-tmp run into, I think filing bugs against the
On Thu, 29 Mar 2012 01:10:19 +0300, Andrei POPESCU wrote:
On Mi, 28 mar 12, 20:47:45, Camaleón wrote:
(...)
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
On Thu, 29 Mar 2012 01:36:36 +0300, Andrei POPESCU wrote:
On Mi, 28 mar 12, 19:57:34, Camaleón wrote:
- The upgrade routine asks the user for this change so this is not
being applied silently but consciously.
IMVHO an entry in the release notes and NEWS.Debian would be necessary,
but
On Jo, 29 mar 12, 14:09:29, Camaleón wrote:
That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for not
having to care about this and the operation I was performing was browsing
a 75 MiB tar.gz file with Midnight Commander. That's simply what flooded
tpmfs and made MC to
On Thu, 29 Mar 2012 18:52:07 +0300, Andrei POPESCU wrote:
On Jo, 29 mar 12, 14:09:29, Camaleón wrote:
That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for not
having to care about this and the operation I was performing was
browsing a 75 MiB tar.gz file with Midnight
On 29/03/12 17:22, Camaleón wrote:
On Thu, 29 Mar 2012 18:52:07 +0300, Andrei POPESCU wrote:
On Jo, 29 mar 12, 14:09:29, Camaleón wrote:
That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for not
having to care about this and the operation I was performing was
browsing a 75 MiB
On Thu, 29 Mar 2012 18:26:15 +0100, Dom wrote:
On 29/03/12 17:22, Camaleón wrote:
On Thu, 29 Mar 2012 18:52:07 +0300, Andrei POPESCU wrote:
On Jo, 29 mar 12, 14:09:29, Camaleón wrote:
That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for
not having to care about this and the
On 29/03/12 18:26, Dom wrote:
Disclaimer: I've never used Midnight Commander
Give it a go, you may fall in love with it, like many have. :)
Keith
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Jo, 29 mar 12, 14:21:58, Camaleón wrote:
I don't usually pay much attention to what NEWS.Debian says
Do you have apt-listchanges installed? It's Priority: standard now.
Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
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
On Ma, 27 mar 12, 14:58:52, Camaleón wrote:
IMO, the rule of thumb for applying a new default is asking ourselves if
the new default will cause any problem to the users. If yes, then
don't touch the old default and keep it the way it was.
I don't agree.
If we are not going to get any
On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
On Ma, 27 mar 12, 14:58:52, Camaleón wrote:
IMO, the rule of thumb for applying a new default is asking ourselves
if the new default will cause any problem to the users. If yes, then
don't touch the old default and keep it the way it
On Wed, Mar 28, 2012 at 8:50 AM, Andrei POPESCU
andreimpope...@gmail.com wrote:
On Ma, 27 mar 12, 14:58:52, Camaleón wrote:
IMO, the rule of thumb for applying a new default is asking ourselves if
the new default will cause any problem to the users. If yes, then
don't touch the old default
On Mi, 28 mar 12, 15:12:19, Camaleón wrote:
On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
On Ma, 27 mar 12, 14:58:52, Camaleón wrote:
IMO, the rule of thumb for applying a new default is asking ourselves
if the new default will cause any problem to the users. If yes, then
On Wed, 28 Mar 2012 19:26:54 +0300, Andrei POPESCU wrote:
On Mi, 28 mar 12, 15:12:19, Camaleón wrote:
On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
On Ma, 27 mar 12, 14:58:52, Camaleón wrote:
IMO, the rule of thumb for applying a new default is asking
ourselves if the new
On Tue, Mar 27, 2012 at 02:58:52PM +, Camaleón wrote:
On Tue, 27 Mar 2012 14:13:23 +0100, Roger Leigh wrote:
As the person who created these defaults, just a few points for everyone
in this thread to consider:
A common (and very persuasive) argument for not mounting a tmpfs on /tmp
On 28/03/12 18:32, Roger Leigh wrote:
On Tue, Mar 27, 2012 at 02:58:52PM +, Camaleón wrote:
On Tue, 27 Mar 2012 14:13:23 +0100, Roger Leigh wrote:
As the person who created these defaults, just a few points for everyone
in this thread to consider:
A common (and very persuasive) argument
On Wed 28 Mar 2012 at 15:12:19 +, Camaleón wrote:
On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
The improvement long term *could* be valuable enough to justify the
pain. The correct way is usually not the easy way.
And what (or who) decides what is correct?
It's my
On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
On Wed, 28 Mar 2012 19:26:54 +0300, Andrei POPESCU wrote:
On Mi, 28 mar 12, 15:12:19, Camaleón wrote:
On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
On Ma, 27 mar 12, 14:58:52, Camaleón wrote:
IMO, the rule of thumb for
On Mi, 28 mar 12, 19:27:52, Dom wrote:
I think the main issue I had was that /tmp was moved to ramfs
without anycomment (that I can recall, I may be wrong) shown by
apt-listchanges. I have been told that it was discussed in the
developers list, but I'm not a Debian dev. I'm a user.
+1 on
On Wed, 28 Mar 2012 18:32:25 +0100, Roger Leigh wrote:
On Tue, Mar 27, 2012 at 02:58:52PM +, Camaleón wrote:
(...)
However, the following points also need to be considered:
- having /tmp on / means that / needs to be writable by default -
having limitless space on /tmp means it
On Wed, 28 Mar 2012 19:12:27 +0100, Brian wrote:
On Wed 28 Mar 2012 at 15:12:19 +, Camaleón wrote:
On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
The improvement long term *could* be valuable enough to justify the
pain. The correct way is usually not the easy way.
And
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,
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
On Mi, 28 mar 12, 19:57:34, Camaleón wrote:
- The upgrade routine asks the user for this change so this is not being
applied silently but consciously.
IMVHO an entry in the release notes and NEWS.Debian would be necessary,
but sufficient.
Kind regards,
Andrei
--
Offtopic discussions among
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
On 28.03.2012 20:27, Dom wrote:
This change has caused me a number of (admittedly not too serious)
problems.
To get a better feeling for what kind of problems users with
tmpfs-on-tmp run into, I think filing bugs against the affected packages
would be a great idea.
Ideally, usertagged, so they
On Sun, Mar 25, 2012 at 12:09 AM, Stan Hoeppner s...@hardwarefreak.com wrote:
On 3/24/2012 4:02 PM, Javier Vasquez wrote:
2012/3/24 shirish शिरीष shirisha...@gmail.com:
# TMPFS_SIZE: maximum size for all tmpfs filesystems if no specific
# size is provided. If no value is provided here, the
On Sun, Mar 25, 2012 at 10:51:07AM +, Camaleón wrote:
On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote:
On Sat, Mar 24, 2012 at 11:10 AM, Camaleón noela...@gmail.com wrote:
You may also consider filing a bug, since the more people report
problems with Debian's new, absurdly
On Tue, 27 Mar 2012 14:13:23 +0100, Roger Leigh wrote:
On Sun, Mar 25, 2012 at 10:51:07AM +, Camaleón wrote:
On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote:
(...)
To me it's just not possible to provide defaults satisfying all
users.
Of course.
But when something that
On 3/24/2012 4:02 PM, Javier Vasquez wrote:
2012/3/24 shirish शिरीष shirisha...@gmail.com:
# TMPFS_SIZE: maximum size for all tmpfs filesystems if no specific
# size is provided. If no value is provided here, the kernel default
# will be used.
TMPFS_SIZE=20%
See, this is as you wish.
On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote:
On Sat, Mar 24, 2012 at 11:10 AM, Camaleón noela...@gmail.com wrote:
You may also consider filing a bug, since the more people report
problems with Debian's new, absurdly small /tmp, the more likely it
is to get fixed.
+5
Why?
On 20120325_010923, Stan Hoeppner wrote:
On 3/24/2012 4:02 PM, Javier Vasquez wrote:
2012/3/24 shirish शिरीष shirisha...@gmail.com:
# TMPFS_SIZE: maximum size for all tmpfs filesystems if no specific
# size is provided. If no value is provided here, the kernel default
# will be used.
On Sun, 25 Mar 2012, Paul E Condon wrote:
I'm sure some/many of you will gasp at that fact I still use EXT2. If
it ain't broke, don't fix it. The /boot and root filesystems are on
EXT2, with all data storage on XFS. Never had problems with EXT2 in
this setup, so it lives on, for now.
please CC me if anybody does answer this, sorry for top-posting.
2012/3/24 shirish शिरीष shirisha...@gmail.com:
Hi all,
I got this error, does anybody know how I can give more space to tmpfs ?
Downloaded, time 4575.50sec, speed 29kB/sec,
shirish शिरीष wrote:
I got this error, does anybody know how I can give more space to tmpfs ?
Downloaded, time 4575.50sec, speed 29kB/sec,
texlive-latex-extra-doc_2009-10_2011.20120322-1_all.debdelta
Error: applying of delta for texlive-latex-extra-doc failed: :
Sorry, not enough disk
2012/3/24 Joey Hess jo...@debian.org:
shirish शिरीष wrote:
I got this error, does anybody know how I can give more space to tmpfs ?
Downloaded, time 4575.50sec, speed 29kB/sec,
texlive-latex-extra-doc_2009-10_2011.20120322-1_all.debdelta
Error: applying of delta for texlive-latex-extra-doc
On Sat, 24 Mar 2012 11:00:49 -0600, Javier Vasquez wrote:
2012/3/24 Joey Hess jo...@debian.org:
shirish शिरीष wrote:
I got this error, does anybody know how I can give more space to tmpfs
?
Downloaded, time 4575.50sec, speed 29kB/sec,
1 - 100 of 105 matches
Mail list logo
