On 16/06/2012 03:43, Serge wrote:
2012/6/15 Jean-Christophe Dubacq wrote:
This is often seen as not a good move to have a user-writable directory
on the system partition(s), since this provides for easy DOS
DoS like what? /tmp on disk have a 5% safety limit available for system,
user can
On Fri, Jun 15, 2012 at 06:37:18AM +0200, Jean-Christophe Dubacq wrote:
Learning not to use /tmp to place large files. Setting TMPDIR=/home/tmp
/tmp is for temporary files, and I expect to place files there as large
as the partition is. I am not interested in analysing the files in what
2012/6/15 Jean-Christophe Dubacq wrote:
This is often seen as not a good move to have a user-writable directory
on the system partition(s), since this provides for easy DOS
DoS like what? /tmp on disk have a 5% safety limit available for system,
user can DoS only his own processes, and he
2012/6/13 Jean-Christophe Dubacq wrote:
Why do people repeat that tmpfs is easy to resize? Yes, you need about 3
commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on
disk, because it's large by default and you don't need to resize it. It's
easier to NOT resize /tmp on
On 15/06/2012 03:11, Serge wrote:
2012/6/13 Jean-Christophe Dubacq wrote:
Why do people repeat that tmpfs is easy to resize? Yes, you need about 3
commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on
disk, because it's large by default and you don't need to resize it.
On 13/06/2012 03:53, Serge wrote:
2012/6/12 Bjørn Mork wrote:
I still think that the easy tmpfs resizing makes it superior for /tmp.
Why do people repeat that tmpfs is easy to resize? Yes, you need about 3
commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on
disk,
Serge sergem...@gmail.com writes:
Since tmpfs+swap is mostly slower than regular filesystem
And the world is flat.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Salvo Tomaselli tipos...@tiscali.it writes:
But does the default have to be maximised for the dumbest possible user?
Or should the default rather be for the intelligent user doing the right
things?
But the intelligent user can change the default hisself, the dumbest
canât. And Debian
Wouter Verhelst wou...@debian.org writes:
On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote:
2012/6/1 Goswin von Brederlow wrote:
So tmpfs would basically never be used despite the benefits.
Well, nobody named the benefits yet.
- You could mount your mail spool there, and make things
Bjørn Mork bj...@mork.no writes:
Petter Reinholdtsen p...@hungry.com writes:
[Bjørn Mork]
I'd like to add another one:
- a tmpfs is always easy to grow without requiring any special
preparations. Just add more swap. The swap could be on different
disks, and could even be files
On Wed, 2012-06-13 at 09:22 +0200, Bjørn Mork wrote:
Serge sergem...@gmail.com writes:
Since tmpfs+swap is mostly slower than regular filesystem
And the world is flat.
Well... if you actually do have to swap, the I/O pattern is currently
not very efficient. See
On Wed, 13 Jun 2012, Ben Hutchings wrote:
On Wed, 2012-06-13 at 09:22 +0200, Bjørn Mork wrote:
Since tmpfs+swap is mostly slower than regular filesystem
And the world is flat.
Well... if you actually do have to swap, the I/O pattern is currently
not very efficient. See
Aneurin Price aneurin.pr...@gmail.com writes:
In anything resembling a 'normal' system (ie. the kind where one might
be using the defaults) I would say that the tmpfs correlation is so
strong as to be very nearly 1:1, and this seems like the crux of the
matter; that is after all the reason
On Tue, Jun 12, 2012 at 01:15:51PM +0200, Bjørn Mork wrote:
Aneurin Price aneurin.pr...@gmail.com writes:
In anything resembling a 'normal' system (ie. the kind where one might
be using the defaults) I would say that the tmpfs correlation is so
strong as to be very nearly 1:1, and this seems
2012/6/12 Bjørn Mork wrote:
I still think that the easy tmpfs resizing makes it superior for /tmp.
Why do people repeat that tmpfs is easy to resize? Yes, you need about 3
commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on
disk, because it's large by default and you
On 8 June 2012 12:04, Bjørn Mork bj...@mork.no wrote:
Any file system will run out of space given the broken applications
mentioned in this thread.
It is not productive to redefine applications as 'broken' simply
because they do not conform to an arbitrary set of requirements that
you have just
Le lundi 11 juin 2012 à 14:53 +0100, Aneurin Price a écrit :
On 8 June 2012 12:04, Bjørn Mork bj...@mork.no wrote:
Any file system will run out of space given the broken applications
mentioned in this thread.
It is not productive to redefine applications as 'broken' simply
because they
Wouter Verhelst wrote:
Also, the symlink attack thing isn't just something I made up;
tmpreaper's REAME.Debian actually warns about that.
It's not particularly hard to securely delete /tmp in single user mode,
ie at boot. Just don't follow symlinks. Tmpreaper's potential for
symlink attacks is
On Sun, Jun 10, 2012 at 12:20:32PM +0200, Wouter Verhelst wrote:
When /tmp is in a tmpfs, it's easy to connect the dots if it's empty on
the next boot, and even easy to understand that restoring there (and
then rebooting) isn't going to be very helpful.
I don’t think the standard user will
I don’t think the standard user will realize the difference between disk
/tmp cleaned at reboot and a RAM disk.
He will realize the difference between a program that works and a program that
informs him of insufficient disk space (if lucky, or just behaving odd
otherwise).
If he is smart he
Aneurin Price aneurin.pr...@gmail.com writes:
(Note that we are talking about applications which fail gracefully
when confronted with ENOSPC,
Are we? What's the problem then?
but which are likely to do so more often when the size of /tmp is
restricted.)
Yes, but the tmpfs correlation is
On 11 June 2012 22:59, Bjørn Mork bj...@mork.no wrote:
Aneurin Price aneurin.pr...@gmail.com writes:
(Note that we are talking about applications which fail gracefully
when confronted with ENOSPC,
Are we? What's the problem then?
Honestly, I have no idea. It's clear that some people think
On Fri, Jun 08, 2012 at 04:59:14PM +0300, Serge wrote:
2012/6/8 Petter Reinholdtsen wrote:
[Wouter Verhelst]
- You could mount your mail spool there, and make things go blazingly
fast [1]
You could, but this is not related to /tmp.
Sure; that was a joke, after all.
- There's no
[Serge]
Well, nobody named the benefits yet.
[Wouter Verhelst]
- You could mount your mail spool there, and make things go blazingly
fast [1]
[...]
- There's no danger of a symlink attack or similar with things like
tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the
Petter Reinholdtsen p...@hungry.com writes:
I've happily been using tmpfs on /tmp/ for probably ten years now, and
can list some more benefits:
- It allow diskless setups like LTSP to work the same way the default
installation in Debian work. They use read-only NFS-mounted file
On Fri, Jun 08, 2012 at 01:04:50PM +0200, Bjørn Mork wrote:
- a tmpfs is always easy to grow without requiring any special
preparations. Just add more swap. The swap could be on different
disks, and could even be files hosted on other file systems.
Yes, of course, now I’m not only wasting
[Bjørn Mork]
I'd like to add another one:
- a tmpfs is always easy to grow without requiring any special
preparations. Just add more swap. The swap could be on different
disks, and could even be files hosted on other file systems.
This sound very similar to what I am doing already
2012/6/8 Petter Reinholdtsen wrote:
[Wouter Verhelst]
- You could mount your mail spool there, and make things go blazingly
fast [1]
You could, but this is not related to /tmp.
- There's no danger of a symlink attack or similar with things like
tmpreaper -- or indeed any need for
Petter Reinholdtsen p...@hungry.com writes:
[Bjørn Mork]
I'd like to add another one:
- a tmpfs is always easy to grow without requiring any special
preparations. Just add more swap. The swap could be on different
disks, and could even be files hosted on other file systems.
This
On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote:
2012/6/1 Goswin von Brederlow wrote:
So tmpfs would basically never be used despite the benefits.
Well, nobody named the benefits yet.
- You could mount your mail spool there, and make things go blazingly
fast [1]
- It speeds things
On Thu, Jun 07, 2012 at 03:24:08PM +0200, Wouter Verhelst wrote:
On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote:
Well, nobody named the benefits yet.
- You could mount your mail spool there, and make things go blazingly
fast [1]
If I remember Wietse’s opinion correctly he will jump
* Wouter Verhelst (wou...@debian.org) [120607 16:06]:
On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote:
2012/6/1 Goswin von Brederlow wrote:
So tmpfs would basically never be used despite the benefits.
Well, nobody named the benefits yet.
- It speeds things up, especially on
Stephan Seitz stse+deb...@fsing.rootsland.net writes:
On Tue, Jun 05, 2012 at 10:33:13AM +0200, Goswin von Brederlow wrote:
Personally I thing DVD ISO images (downloaded) belong in your $HOME
Donât you think this is getting quite ridiculous? Big temporary
files belong in your $HOME, but
On Wed, Jun 06, 2012 at 11:09:31AM +0200, Goswin von Brederlow wrote:
Stephan Seitz stse+deb...@fsing.rootsland.net writes:
Don’t you think this is getting quite ridiculous? Big temporary
files belong in your $HOME, but small temporary files in /tmp? Only to
switch /tmp from disk to RAM?
No, I
But does the default have to be maximised for the dumbest possible user?
Or should the default rather be for the intelligent user doing the right
things?
But the intelligent user can change the default hisself, the dumbest
can’t. And Debian does allow the inexperienced user to install his
Stephan Seitz stse+deb...@fsing.rootsland.net writes:
On Fri, Jun 01, 2012 at 02:19:53PM +0200, Goswin von Brederlow wrote:
In general your option assumes that you need the maximum amount of free
space in /tmp. That is simply not true. In most cases a small /tmp is
just peachy. Because of this
On Tue, Jun 05, 2012 at 10:33:13AM +0200, Goswin von Brederlow wrote:
Personally I thing DVD ISO images (downloaded) belong in your $HOME
Don’t you think this is getting quite ridiculous? Big temporary files
belong in your $HOME, but small temporary files in /tmp? Only to switch
/tmp from
On Mon, Jun 04, 2012 at 06:34:57AM +0300, Serge wrote:
2012/6/3 Toni Mueller wrote:
First, there can be rather large session directory, you probably don't
want ~365595 files to be always eating your RAM.
Well, I much rather want that, or store the session data in memcache,
which is
On Sat, Jun 02, 2012 at 05:11:16PM +0300, Serge wrote:
2012/6/2 Toni Mueller wrote:
Eg. web application's session data very frequently goes there, and/or
the sysadmin wants it to go onto a tmpfs.
First, there can be rather large session directory, you probably don't
want ~365595 files
2012/6/3 Toni Mueller wrote:
First, there can be rather large session directory, you probably don't
want ~365595 files to be always eating your RAM.
Well, I much rather want that, or store the session data in memcache,
which is almost the same thing, only with a different label.
Memcache?
On 06/02/2012 10:11 PM, Serge wrote:
First, there can be rather large session directory, you probably don't
want ~365595 files to be always eating your RAM. Second, session data
MUST NOT be lost on reboot by default. So even without /tmp, sysadmin
should not put session data on tmpfs. There're
2012/6/2 Bruce Sass wrote:
Maintainer will probably write a better code.
Much better... if TMPTIME != 0 it will be necessary to mount the FS based
/tmp, clean it, create a tmpfs, move anything left in /tmp to the tmpfs,
then mount --bind the tmpfs on /tmp.
Oh... I was not thinking about
On Sat, Jun 02, 2012 at 12:48:03PM +0300, Serge wrote:
Oh... I was not thinking about TMPTIME. Does it mean that there's no way
we can mount /tmp to tmpfs because it breaks TMPTIME?
Well, I think, as long as this setting exist, no. With „-1” you can even
disable tmp cleaning. So if the admin
On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote:
Well, nobody named the benefits yet. Just the problems. There were a
Well, I named one on 28th of May. Did you read it?
Kind regards,
--Toni++
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Fri, Jun 01, 2012 at 07:21:40PM +0200, Stephan Seitz wrote:
/tmp is for temporary files, so I expect my /tmp to hold all these
files, in my case DVD ISO images (downloaded or localy generated)
that I will burn and then delete. So my /tmp is at least 20GB.
BluRay users may need more.
If you
2012/6/2 Toni Mueller wrote:
Well, nobody named the benefits yet. Just the problems. There were a
Well, I named one on 28th of May. Did you read it?
Sorry, I was trying to send not so many messages then, and I had not
answered yours. I guess you talk about these:
Eg. web application's
On Sat, Jun 02, 2012 at 02:56:03PM +0200, Philipp Kern wrote:
If you assume an unexpected reboot, then all that data will be lost,
Well, I can count my unexpected reboots in the last years with one hand,
so this is not a problem. And as already mentioned, you can configure
with TMPTIME in
On June 2, 2012 03:48:03 AM Serge wrote:
2012/6/2 Bruce Sass wrote:
Maintainer will probably write a better code.
Much better... if TMPTIME != 0 it will be necessary to mount the FS based
/tmp, clean it, create a tmpfs, move anything left in /tmp to the tmpfs,
then mount --bind the
Serge sergem...@gmail.com writes:
2012/5/28 Roger Leigh wrote:
The primary cause of problems is simply that the tmpfs /tmp isn't big
enough. [...] what guarantees are offered by the system in terms of
minimum and maximum available space on /tmp? [...] Consider the default:
/tmp is on the
2012/6/1 Goswin von Brederlow wrote:
That should be:
mount /tmp to tmpfs only when amount of free space in /tmp is fewer
than the tmpfs would have or when /tmp is currently read-only.
Yes, of course. IIRC current script already checks for read-only root.
So this check don't have to be
On Fri, Jun 01, 2012 at 02:19:53PM +0200, Goswin von Brederlow wrote:
In general your option assumes that you need the maximum amount of free
space in /tmp. That is simply not true. In most cases a small /tmp is
just peachy. Because of this it is hard to set a minimum size where
tmpfs would be
On June 1, 2012 10:00:52 AM Serge wrote:
...
I considered that. I was just trying to keep description shorter and
easier to understand. A more complete description would look like:
0. fstab is already processed and /tmp was (or was not) mounted to a
separate partition.
1. init-script
52 matches
Mail list logo
