Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 syst

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 process

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 tempo

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 r

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 /t

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

On Wed, 2012-06-13 at 09:22 +0200, Bjørn Mork wrote: > Serge 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 . Ben.

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Bjørn Mork writes: > Petter Reinholdtsen 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 oth

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Wouter Verhelst 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 go bl

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Salvo Tomaselli 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 does all

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Serge 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: http://lists.debian.org/874nqfn0af..

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 >

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 don

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

On Tue, Jun 12, 2012 at 01:15:51PM +0200, Bjørn Mork wrote: Aneurin Price 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 matte

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Aneurin Price 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 that these application

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

On 11 June 2012 22:59, Bjørn Mork wrote: > Aneurin Price 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 storing 'large' temporary fi

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Aneurin Price 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 weak. There is absol

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

> 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

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 real

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Le lundi 11 juin 2012 à 14:53 +0100, Aneurin Price a écrit : > On 8 June 2012 12:04, Bjørn Mork 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

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

On 8 June 2012 12:04, Bjørn Mork 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 added, espe

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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. > >>

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Petter Reinholdtsen 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 sound

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 f

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[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

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 R

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Petter Reinholdtsen 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 >systems and a

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[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 t

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

* 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, especi

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 on

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 thin

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

> >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 inst

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

On Wed, Jun 06, 2012 at 11:09:31AM +0200, Goswin von Brederlow wrote: Stephan Seitz 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 just don't consider a 4.7GiB do

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Stephan Seitz 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 small temporary files in /tmp

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 dis

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Stephan Seitz 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 it is hard to set a minimu

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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, > > whic

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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: Idea: mount /tmp to tmpfs depending on free space and RAM

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. Memca

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 --b

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 /et

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 s

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 "unsubscr

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 w

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 c

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 to

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

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 add

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

Serge 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 rootfs (whic

Idea: mount /tmp to tmpfs depending on free space and RAM

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 rootfs (which [...] may have lots o