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 system, user can DoS only his own processes, and he can do that anyway. But /tmp on tmpfs is even worse move, since it does not have 5% safety. 1) With 2TB disks, I certainly do not use 5% any more How is that? Isn't it a default value for 2TB disks any more? Or you mean that you manually reduced it to e.g. 1%? Yes. That's the thing I do on most partitions (large ones). 2) Mysql, apache, postfix, all kind of vital systems, do not run as root. And if /tmp is full (and mounted on /), / is full (and so is /var). All kind of mayhem may happen there (I have seen it). You talk about mysql/apache/postfix, so I assume you mean a server. And since it's about users filling /tmp I assume it's a multiuser server (or rather at-least-one-user server). Then putting /tmp on tmpfs is a bad idea there, because doing that will force users to use /var/tmp for large files and will (not can, but will, since /var/tmp is not cleaned) eventually fill /var partition, which is exactly what you need to prevent. Strangely enough, most users do not seem to know about /var/tmp. So, when they put large files, they tend to do that in (IMO better) other places: * $HOME/Desktop * $HOME * $HOME/Downloads * $HOME/theplaceIamworking which is better in terms of system management (except that it is also on NFS, and they suffer terrible pain because of that). Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
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 temporary directory they belong today. Besides if you set TMPDIR to /home/tmp, you don’t need /tmp at all, no matter if tmpfs or not. If you want a system tmp create one and set TMPDIR for these system services. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
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 processes, and he can do that anyway. But /tmp on tmpfs is even worse move, since it does not have 5% safety. 1) With 2TB disks, I certainly do not use 5% any more How is that? Isn't it a default value for 2TB disks any more? Or you mean that you manually reduced it to e.g. 1%? 2) Mysql, apache, postfix, all kind of vital systems, do not run as root. And if /tmp is full (and mounted on /), / is full (and so is /var). All kind of mayhem may happen there (I have seen it). You talk about mysql/apache/postfix, so I assume you mean a server. And since it's about users filling /tmp I assume it's a multiuser server (or rather at-least-one-user server). Then putting /tmp on tmpfs is a bad idea there, because doing that will force users to use /var/tmp for large files and will (not can, but will, since /var/tmp is not cleaned) eventually fill /var partition, which is exactly what you need to prevent. To solve this problem I can suggest: 1. Leave /tmp on /, but have separate /var partition (common for servers), filling /tmp will not fill /var then. Optionally symlink /var/tmp to /tmp. 2. Have *both* /tmp and /var/tmp mount-bound to /home/tmp. 3. Configure quotas for /tmp, wherever it is. Obviously it must be on disk, quotas don't work for tmpfs (it's just ~5 commands to set up quotas). These do not solve the problem completely, there other ways to fill /var without using /tmp. But it should at least save it from accidental fill. And they don't need tmpfs-like resizes. :) (even involuntary; I know of people daily working with 30GB files, and this easily fills the / partition). Is there anything better for them than /tmp on disk? If it's a desktop with single disk I would suggested them a single root partition (with /tmp on it). If it's a server with small root but large /home on RAIDs then I would mount-bind /tmp to /home/tmp... Learning not to use /tmp to place large files. Setting TMPDIR=/home/tmp is a start, indeed. Hm. But that's almost the same as mount-bind /tmp to /home/tmp. Actually mount-bind is even better, because you don't have to explain users when they should set TMPDIR, just say Use default (/tmp) and don't worry, admins will decide on which partition/ram/swap the files will end up. -- Serge -- 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/caovenepobubu0gr6ewqeuk5fabsbt8zqnperedvd2ap5rup...@mail.gmail.com
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 /tmp on disk then resize /tmp on tmpfs, isn't it? ;) Obviously, you only think of /tmp as mounted on /. It was about /tmp on disk in general, but as long as default is to have everything on a root partition - it does not matter where exactly it is. For more complex configurations I suggested several Alternatives (e.g. mount-bind to /home/tmp), each of them is usually better than tmpfs, and don't need tmpfs-like resizes. 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 can do that anyway. But /tmp on tmpfs is even worse move, since it does not have 5% safety. (even involuntary; I know of people daily working with 30GB files, and this easily fills the / partition). Is there anything better for them than /tmp on disk? If it's a desktop with single disk I would suggested them a single root partition (with /tmp on it). If it's a server with small root but large /home on RAIDs then I would mount-bind /tmp to /home/tmp... -- Serge -- 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/caoveneq556_lkm4rblvynfx5ako1qgcllk-kg4jrgxke4vn...@mail.gmail.com
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 resize it. It's easier to NOT resize /tmp on disk then resize /tmp on tmpfs, isn't it? ;) Obviously, you only think of /tmp as mounted on /. It was about /tmp on disk in general, but as long as default is to have everything on a root partition - it does not matter where exactly it is. For more complex configurations I suggested several Alternatives (e.g. mount-bind to /home/tmp), each of them is usually better than tmpfs, and don't need tmpfs-like resizes. 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 can do that anyway. But /tmp on tmpfs is even worse move, since it does not have 5% safety. 1) With 2TB disks, I certainly do not use 5% any more 2) Mysql, apache, postfix, all kind of vital systems, do not run as root. And if /tmp is full (and mounted on /), / is full (and so is /var). All kind of mayhem may happen there (I have seen it). (even involuntary; I know of people daily working with 30GB files, and this easily fills the / partition). Is there anything better for them than /tmp on disk? If it's a desktop with single disk I would suggested them a single root partition (with /tmp on it). If it's a server with small root but large /home on RAIDs then I would mount-bind /tmp to /home/tmp... Learning not to use /tmp to place large files. Setting TMPDIR=/home/tmp is a start, indeed. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
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 disk, because it's large by default and you don't need to resize it. It's easier to NOT resize /tmp on disk then resize /tmp on tmpfs, isn't it? ;) Obviously, you only think of /tmp as mounted on /. 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 (even involuntary; I know of people daily working with 30GB files, and this easily fills the / partition). -- Jean-Christophe Dubacq (beating a dead horse) signature.asc Description: OpenPGP digital signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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: http://lists.debian.org/874nqfn0af@nemi.mork.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 does allow the inexperienced user to install his system. Sometimes people are intelligent but that doesn't mean that they are willing to spend days just to fix these problems, maybe being intelligent doesn't make you interested in learning obscure switches for debian. (and knowing these doesn't make one intelligent). So it's not about stupid users, it's about having a configuration that works by default, without requiring people to go throu mailing lists to learn what they need to install debian and have it working. I agree with your argument but not your conclusion. I think the focus should be more on intelligent users and to get new/dumb users to become intelltigent. So the argument that intelligent users can change the default is besides the point. They shouldn't have to. Also I'm too unwilling to spend days just to fix the stupid partitioning. The default should be good enough for almost everyone. And I have to argue that that means LVM with a few volumes. At least root, swap, var and home. And leave plenty of free space so filesystems can be easily grown as needed. It will never be possible to have one default partitioning that will perfectly suite everyone. So instead the goal should be to have a flexible starting point that makes it easy to make it fit the users needs, esspecially after the installation when a new user actually figures out what is needed. You say configuring the size of tmp is too hard because it is such a black box thing you need days to figure it out. So why not focus on making it easier? I already suggested that packages that need large space in /tmp should check the size on install and point to a relevant file documenting how to set the size for tmp better. I would even go further and say that DI should figure out the initial size/type for /tmp (and swap if tmpfs is used) based on the hardware and packages it is going to install. Why shouldn't the default partitioning differ for a desktop system and a mailserver? Isn't the partitioning before knowing what will be installed later backward? MfG Goswin -- 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/87sjdzo9xt.fsf@frosties.localnet
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 go blazingly fast [1] Some month ago there was a /. article (sorry, don't have a link) about a mail service achieving 99% compression on mail spools and being balzingly fast speading mails like crazy. And yes, they keep all mails in ram. Any disk access would just slow down spreading the mails around. 8-) - It speeds things up, especially on systems with loads of RAM and no swapspace: whenever there's a possibility of disk access, no matter how remote, you risk slowing things down due to that disk access. Reducing disk access for things that don't need to be stored forever is *good*. On that note it also keeps the disk free to read/write other stuff. Like the next input file or storing the final output file. On a cold cache that can make a difference. - anything which reduces the number of possible disk accesses is good for people using SSDs (I have a laptop with SSD, and no swap, and love tmpfs for precisely that reason). - In the (on laptops and desktops) fairly common one-partition-for-everything set-up, there's no risk of a runaway process eating up your diskspace with huge files in /tmp and therefore making it impossible for syslogd to write anything to disk anymore so you can figure out what the f*** happened - It makes for an interesting I need to compile something quickly just to test something out area, where it doesn't matter if you forget to clean up after the fact (yes, this is a bit of an abuse of /tmp; never the less, I find myself doing such things in /tmp fairly often now that /tmp is a tmpfs) Me too. - it's called *tmp*fs for a reason (no, that's not a benefit. Yes, that's an argument in favour) - There's no danger of a symlink attack or similar with things like tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the system, and /tmp is clean again, no matter what was there before. This is more than just a convenience. - No time wasted at boot to clean up /tmp. No journal replay, no fsck. [1] As demonstrated on FreeBSD in http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20041101/msg00145.html. No, I'm not being serious. MfG Goswin -- 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/87obono9m0.fsf@frosties.localnet
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 hosted on other file systems. This sound very similar to what I am doing already with LVM and online file system growing. A simple 'lvresize' and 'ext2resize' (or just debian-edu-fsautoresize for those of us with that tool available) later the full file systems have more free space again. :) Did I misunderstand you? No, but those require LVM and available raw disk space. Swap can always be added without any such preparation. Bjørn And tmpfs is the only filesystem you can also shrink again. MfG Goswin -- 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/87ipevo9fz.fsf@frosties.localnet
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 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 http://lwn.net/Articles/500198/. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
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 http://lwn.net/Articles/500198/. Yes, and fixing that for good would give us an entirely new world of benefits. But it is also a damn hard problem, or it'd have been fixed a long time ago... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120613123921.gb26...@khazad-dum.debian.net
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 that these applications are failing when /tmp is switched to tmpfs. I agree that's likely for any system using a default disk layout, so my comment was irrelevant for this discussion. I still think that the easy tmpfs resizing (no meta data update, no LVM requirements, can use available space on other file systems) makes it superior for /tmp. But most users won't know that they can do this, so we might need a daemon monitoring /tmp and doing ondemand resizing. 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/87lijsok60@nemi.mork.no
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 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 that these applications are failing when /tmp is switched to tmpfs. I agree that's likely for any system using a default disk layout, so my comment was irrelevant for this discussion. I agree as well. This is the main reason why I didn’t like tmpfs to be the default. In most desktop cases you won’t have disk space problems. Even with multiple partitions you can easily spare 20 - 30 GB for a separate tmp partition. I still think that the easy tmpfs resizing (no meta data update, no LVM requirements, can use available space on other file systems) makes it superior for /tmp. But most users won't know that they can do this, so we might need a daemon monitoring /tmp and doing ondemand resizing. While you can resize tmpfs easily, you will never get sizes you would get with disks. And you must backup tmpfs with RAM and swap, so you can’t simply say, I resize my tmpfs to 20 GB if you only have 4 GB RAM and 8 GB swap (but a 2 TB disk). Since you can’t change the partition layout on the fly to grow the swap partition, your daemon would have to create swap files and activate them according to the tmpfs needs. But there will you place these files? You must make sure that the daemon deletes them if they are not needed anymore. After a system crash they must be deleted, or your system will have less and less disk space because orphaned swap files are filling the disk. Will this be worth the trouble? I don’t think so. If you see an advantage having /tmp on tmpfs, you can manually do so. Then you know what you have done. I don’t care if we get a new /tmpfs together with /tmp, so the user has both choices to set TMDPIR according to his needs. We may even patch some applications creating small shortlived temporary files to use /tmpfs instead in Debian. But by default we should not give up disk based /tmp for a default installation. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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't need to resize it. It's easier to NOT resize /tmp on disk then resize /tmp on tmpfs, isn't it? ;) And there's more. You can't separate application data from your files on tmpfs in swap. But you can do that on a regular filesystem. You can dedicate /tmp directory to a separate partition/disk. Or you can balance it among several partitions (see `mhddfs`). You can't do that with tmpfs. we might need a daemon monitoring /tmp and doing ondemand resizing. Since tmpfs+swap is mostly slower than regular filesystem and may generate more writes... I can't think of any cases where such daemon would be better than a usual /tmp on disk. But if you need it somewhy... check swapd. PS: I'm curious can swap-files break suspend-to-disk even for users having a separate swap partition? -- Serge -- 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/caovenepqrpbawuscncvvnd_dumd5te4hbtp4tpn-r-e4mb3...@mail.gmail.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 added, especially when you haven't even given any indication of what you consider 'non-broken' behaviour. The use of /tmp (or TMPDIR if set) to store temporary files is its *purpose*. If suddenly that use is considered 'broken' behaviour, then who is to say what other standard behaviour will be declared 'broken' tomorrow? I could declare that from now on I'm going to use FAT32 for my /tmp, and all applications which expect a case-sensitive filesystem are broken, but it would be similarly absurd. -- 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/CAHb+SPBD-t34i_z6o=mg0sk9j2qurga1kzvjtodes73w5u4...@mail.gmail.com
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 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 added, especially when you haven't even given any indication of what you consider 'non-broken' behaviour. Right. So your applications are not broken because they all have access to infinite storage? Your life must be so fantastic. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1339423495.4245.209.camel@pi0307572
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 entirely due to it being run in multiuser mode, which provides the potential for users to race it. Thankfully, tmpreaper is not included in the base system, although I would still prefer it not be included in Debian at all, because IMHO it's a security hole waiting to happen, as well as a Debian-specific fork that has now missed out on 14 years (!!!) of upstream development and, presumably, security improvements. http://bugs.debian.org/71251 -- see shy jo signature.asc Description: Digital signature
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 realize the difference between disk /tmp cleaned at reboot and a RAM disk. Also, the symlink attack thing isn't just something I made up; tmpreaper's REAME.Debian actually warns about that. True, but tmpreaper is not needed for systems with frequent reboots. /tmp on disk is cleaned according to the setting of TMPTIME. You need tmpreaper to clean /tmp on systems which rarely reboot. And then you have the same problem with tmpfs. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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 will use the information to figure out what the problem is and solve it, otherwise he might just think that it's very odd that it's 1TB disk is already full. -- Salvo Tomaselli -- 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/201206111828.39894.tipos...@tiscali.it
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 weak. There is absolutely no guarantee that there will be more space available on the root file system than a default tmpfs. 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/87d355pl0v@nemi.mork.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 storing 'large' temporary files in /tmp is 'broken', for unspecified values of 'large', but I don't understand why and nobody seems interesting in explaining the reasoning when they can just declare it axiomatic. My best reasoning is that the application shouldn't fail at all in this case, but should find some way of working despite running out of storage space. Obviously that would be great, but I can't really imagine all that many cases where it's likely to be possible (or really *any* cases where it's likely to be worth going to the extra trouble). It does annoy me quite a lot that people are calling applications broken without even *attempting* to define what they might deign to call *not* broken. 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 absolutely no guarantee that there will be more space available on the root file system than a default tmpfs. 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 applications are failing when /tmp is switched to tmpfs. It is almost a complete certainty that on any given system there will be more space available on the root filesystem than a default tmpfs, unless that system has requirements so specific that the choice of defaults is moot. Sure there's no *guarantee*, but it is exceptionally likely; if you do seriously believe otherwise (ie. you're not just pointing out that it *might* not be the case), I'd say that's sufficiently extraordinary a claim as to require extraordinary evidence. -- 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/cahb+spbfe0zcryetorxbnu0mfdfoncmme_qcykhznyjj73v...@mail.gmail.com
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. - There's no danger of a symlink attack or similar with things like tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the system, and /tmp is clean again, no matter what was there before. This is more than just a convenience. This works for many years. /tmp on disk is also cleaned on reboot. Yes, but that does have its downsides: - It can be surprising to those who don't know about that fact (whaddaya mean, it's gone? This is disk, right?) - Removing files takes time, especially if there's large amounts of files in that directory. The two combined once made me wonder why booting my laptop took much longer than usual after I had just restored some dozens of gigabytes from bacula (which stores files in /tmp by default), and had forgotten about the automatic cleaning. 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. Also, the symlink attack thing isn't just something I made up; tmpreaper's REAME.Debian actually warns about that. [...] -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120610102032.ga9...@grep.be
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 the system, and /tmp is clean again, no matter what was there before. This is more than just a convenience. 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 writable tmpfs mounted on /tmp/. - It reduces the number of disk writes on a laptop, allowing it to spin down the disk a bit longer. -- Happy hacking, Petter Reinholdtsen -- 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/2fltxymku23@login2.uio.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 systems and a writable tmpfs mounted on /tmp/. - It reduces the number of disk writes on a laptop, allowing it to spin down the disk a bit longer. 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. Any file system will run out of space given the broken applications mentioned in this thread. tmpfs is the only one which will allow all systems to dynamically add more space, only limited by the available disks. That's why tmpfs should be the default for both new and old systems, unless the administrator has explicitly made a more limited choice. 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/87lijyqd2l@nemi.mork.no
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 RAM for tmpfs but disk space for swap files? Any file system will run out of space given the broken applications mentioned in this thread. tmpfs is the only one which will allow all tmpfs will run out of space much ealier than your 2TB disk. systems to dynamically add more space, only limited by the available disks. That's why tmpfs should be the default for both new and old ROTFL, yes, of course. I can get my tmpfs bigger than my disk to back it up. Sorry, this is ridiculous. If I have enough disks available I can grow my tmp partition (or my root partition with tmp) with LVM without problems as well. Both things are nothing a standard desktop user can do by its own, but the standard desktop user will certainly have more disk space than RAM, so I’m glad this tmpfs for tmp crap is off by default. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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 with LVM and online file system growing. A simple 'lvresize' and 'ext2resize' (or just debian-edu-fsautoresize for those of us with that tool available) later the full file systems have more free space again. :) Did I misunderstand you? Any file system will run out of space given the broken applications mentioned in this thread. tmpfs is the only one which will allow all systems to dynamically add more space, only limited by the available disks. That's why tmpfs should be the default for both new and old systems, unless the administrator has explicitly made a more limited choice. While I agree that tmpfs should be the default, I suspect this argument isn't solid enough to make it worth it. There are luckily other arguments too. :) -- Happy hacking Petter Reinholdtsen -- 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/2flobouko0q@login2.uio.no
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 for tmpreaper anymore. You reboot the system, and /tmp is clean again, no matter what was there before. This is more than just a convenience. This works for many years. /tmp on disk is also cleaned on reboot. - 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 writable tmpfs mounted on /tmp/. But `mount --bind /tmp /home/tmp` or /tmp-/var/tmp also allows read-only NFS root. And it's even better, because it gives you more free RAM, which is usually very important for LTSP stations. - It reduces the number of disk writes on a laptop, allowing it to spin down the disk a bit longer. It does not, because /tmp is mostly unused by default. On the contrary vm.laptop_mode=1 do it much better than tmpfs. :) There are luckily other arguments too. :) I start thinking that if you use /tmp on tmpfs you're doing something wrong or rather if you use /tmp on tmpfs you've missed a better option. :) -- Serge -- 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/CAOVenEpvyJG4q_qsehDutb+C1rYvM6SY1fKrsMbKiL9jiv=z...@mail.gmail.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 sound very similar to what I am doing already with LVM and online file system growing. A simple 'lvresize' and 'ext2resize' (or just debian-edu-fsautoresize for those of us with that tool available) later the full file systems have more free space again. :) Did I misunderstand you? No, but those require LVM and available raw disk space. Swap can always be added without any such preparation. 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/87d359qyxb@nemi.mork.no
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 things up, especially on systems with loads of RAM and no swapspace: whenever there's a possibility of disk access, no matter how remote, you risk slowing things down due to that disk access. Reducing disk access for things that don't need to be stored forever is *good*. - anything which reduces the number of possible disk accesses is good for people using SSDs (I have a laptop with SSD, and no swap, and love tmpfs for precisely that reason). - In the (on laptops and desktops) fairly common one-partition-for-everything set-up, there's no risk of a runaway process eating up your diskspace with huge files in /tmp and therefore making it impossible for syslogd to write anything to disk anymore so you can figure out what the f*** happened - It makes for an interesting I need to compile something quickly just to test something out area, where it doesn't matter if you forget to clean up after the fact (yes, this is a bit of an abuse of /tmp; never the less, I find myself doing such things in /tmp fairly often now that /tmp is a tmpfs) - it's called *tmp*fs for a reason (no, that's not a benefit. Yes, that's an argument in favour) - There's no danger of a symlink attack or similar with things like tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the system, and /tmp is clean again, no matter what was there before. This is more than just a convenience. [1] As demonstrated on FreeBSD in http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20041101/msg00145.html. No, I'm not being serious. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120607132408.gi21...@grep.be
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 your throat if you put the postfix mail spool on tmpfs. Maybe it could be used for amavis tmp directory, if you have enough RAM or small enough mails. - It speeds things up, especially on systems with loads of RAM and no swapspace: whenever there's a possibility of disk access, no matter It may do so, but how many Debian user have so much RAM and/or so less disk space, that it can be used as default (yes, luckily it was changed)? - anything which reduces the number of possible disk accesses is good for people using SSDs (I have a laptop with SSD, and no swap, and love tmpfs for precisely that reason). So, you have /var/log on tmpfs as well (or a remote log server)? Don’t you think that you are doing more writes to /var or $HOME than to tmp? Besides SSDs aren’t so wide spread (and in my eyes too unsecure yet) that you should optimize for them as default. - In the (on laptops and desktops) fairly common one-partition-for-everything set-up, there's no risk of a runaway process eating up your diskspace with huge files in /tmp and therefore But runaway processes may fill your disk with log entries. I have seen a catalina.out with the size of several gigabytes. - It makes for an interesting I need to compile something quickly just to test something out area, where it doesn't matter if you forget to clean up after the fact (yes, this is a bit of an abuse of /tmp; never the less, I find myself doing such things in /tmp fairly often now that /tmp is a tmpfs) Probably true. The only thing I compile myself is the Linux kernel, and I want to keep it. But again, nothing that is worth as default installation. - There's no danger of a symlink attack or similar with things like tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the system, and /tmp is clean again, no matter what was there before. This is more than just a convenience. The existance of TMPTIME shows that there are more than enough people who don’t want to loose the contents of their /tmp with every reboot. Besides tmpreaper exists so you clean your /tmp without the need to reboot. There are certainly advantages of tmpfs, but I don’t see it in /tmp for most systems. But the installer may give you the choise (or create as standard) to have a /tmpfs with tmpfs, so every user who wants to use it, can set their own TMPDIR. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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, especially on systems with loads of RAM and no swapspace: whenever there's a possibility of disk access, no matter how remote, you risk slowing things down due to that disk access. Reducing disk access for things that don't need to be stored forever is *good*. For example, at least one debian buildd runs all the builds completly in a ramdisk. Why not? Andi -- 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/20120607150639.gw2...@mails.so.argh.org
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 small temporary files in /tmp? Only to switch /tmp from disk to RAM? No, I just don't consider a 4.7GiB download a temporary thing. I still have the mindset that that should take time, cost money and therefore be precious and should not be lost on reboot. somewhere. And locally generated should just pipe the image to the burner unless you want to upload the image somewhere, in which case Or you want to keep it safe, until you are sure the burned DVD is working. Of course, if I want to keep the ISO it will be stored in $HOME, but then it isnât a *temporary* file anymore. And /tmp *is* for temporary files. $HOME again. Just imagine a power failure after you painstackingly uploaded 99.9% of the iso and then you have to start from scratch again because a reboot cleans /tmp. TMPTIME exists and can be set according to your needs and your safety concern. Yeah, as noticed somewhere else TMPTIME conflicts with tmpfs. Didn't even know that variable existed. So many hidden magic things to configure stuff ... Just out of interest: Do you have /tmp on /? Because if you do already have a seperate /tmp partition then that obviously stays used. I always have separate partitions for /, /usr, /var, /tmp, /usr/local and /home (allright, with crappy software like udev and Co. which starts wanting files in /usr needlessy at the early boot stages, I will merge / and /usr in time). It isnât a problem for me. But we are talking about defaults. You wish to tell new users that there two TB disk canât really be used as they wish because Debian has a strange distinction between temporary files belonging in /tmp and temporary files donât belonging in /tmp? 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? According to the discussion the installer will create one partition for swap and one for /. If this is true then the standard user has far more space on disk than he has RAM. Just wait one more release and it will only be one partition with swap files. And lets give that partition a drive letter like C:\. :) I realy don't like the direction DI is taking there. Shade and sweet water! Stephan MfG Goswin -- 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/873968ajsk.fsf@frosties.localnet
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 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 just don't consider a 4.7GiB download a temporary thing. I still have the mindset that that should take time, cost money and therefore be precious and should not be lost on reboot. Well, everything you do with your computer will cost money. The download will take its time, yes, but you don’t have to wait for it to be finished. But for me your example still describes a temporary file *if* I want to delete the file after I burned the ISO. 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 system. According to the discussion the installer will create one partition for swap and one for /. If this is true then the standard user has far more space on disk than he has RAM. Just wait one more release and it will only be one partition with swap files. And lets give that partition a drive letter like C:\. :) I realy don't like the direction DI is taking there. ROTFL, yes maybe. I agree that I don’t like one big partition as well, but how do you want to partition a disk by default? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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 install his system. Sometimes people are intelligent but that doesn't mean that they are willing to spend days just to fix these problems, maybe being intelligent doesn't make you interested in learning obscure switches for debian. (and knowing these doesn't make one intelligent). So it's not about stupid users, it's about having a configuration that works by default, without requiring people to go throu mailing lists to learn what they need to install debian and have it working. -- Salvo Tomaselli -- 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/201206061938.27022.tipos...@tiscali.it
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 it is hard to set a minimum size where tmpfs would be too small to be usefull. For some user that would be 100MB, for others it is 100GB. /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. So you are one of the 100GB users. Personally I thing DVD ISO images (downloaded) belong in your $HOME somewhere. And locally generated should just pipe the image to the burner unless you want to upload the image somewhere, in which case $HOME again. Just imagine a power failure after you painstackingly uploaded 99.9% of the iso and then you have to start from scratch again because a reboot cleans /tmp. If this is not the meaning of /tmp, then rename it. Diskspace is cheap and easier to spare than my RAM. So, yes, if someone has one 3TB partition which is writeable, then /tmp belongs to disk not to RAM. Shade and sweet water! Stephan Just out of interest: Do you have /tmp on /? Because if you do already have a seperate /tmp partition then that obviously stays used. MfG Goswin -- 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/87pq9ecg52.fsf@frosties.localnet
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 disk to RAM? somewhere. And locally generated should just pipe the image to the burner unless you want to upload the image somewhere, in which case Or you want to keep it safe, until you are sure the burned DVD is working. Of course, if I want to keep the ISO it will be stored in $HOME, but then it isn’t a *temporary* file anymore. And /tmp *is* for temporary files. $HOME again. Just imagine a power failure after you painstackingly uploaded 99.9% of the iso and then you have to start from scratch again because a reboot cleans /tmp. TMPTIME exists and can be set according to your needs and your safety concern. Just out of interest: Do you have /tmp on /? Because if you do already have a seperate /tmp partition then that obviously stays used. I always have separate partitions for /, /usr, /var, /tmp, /usr/local and /home (allright, with crappy software like udev and Co. which starts wanting files in /usr needlessy at the early boot stages, I will merge / and /usr in time). It isn’t a problem for me. But we are talking about defaults. You wish to tell new users that there two TB disk can’t really be used as they wish because Debian has a strange distinction between temporary files belonging in /tmp and temporary files don’t belonging in /tmp? According to the discussion the installer will create one partition for swap and one for /. If this is true then the standard user has far more space on disk than he has RAM. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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, which is almost the same thing, only with a different label. Memcache? (0_o) Imho, that's even worse than store it on tmpfs, since memcache can just push your data off the cache and you'll get it lost even without reboot. I can think of session data in memcache only as some hack for load-balanced servers, Not to be debated - yes, using memcached does create a headache or two, but also solves problems that are otherwise hard. Yes, reboots are rare enough (every few weeks at most) to ignore their adverse side effect on user's sessions - at least in my use cases. but it requires careful memory configuration, otherwise users may find themselves logged off in the middle of a chat. No objections here. Mind you, all these things are done to *prevent* the application from going to disk, and force it to stay in RAM. And that's exactly what I want. You already have a filesystem cache for that. Session data stays in RAM if it is used. But it does not get lost when inactive for a few hours. Well, it doesn't. I have copious memory in a box that is highly underused ( 50%), but still find that interesting files, or file system data, are deleted from that cache. Which leads to very high access times in case I need this data. Plain users I've seen expect their session to stay alive for days. I.e. they have just checked the forum and then turned off PC. When tomorrow they turn it on they expect to be still logged in. Hmmm. First, I'd say that this assumption on their behalf is wrong. Secondly, over here, people tend to be forcefully disconnected at least every 24 hours, forcing a new client IP, anyway. There is no sane way to keep users logged in under these circumstances. They expect this to be true for everything (forums, blogs, web-email, etc). It's a disaster for them to be logged off, it takes hours to find a piece of paper where they wrote the password. They become angry if 10 minutes ago they were logged in and now they aren't, they don't care that I had to reboot the server. Looks like you have a vastly different user population, who also use a vastly different software. My clients' software packages just automatically re-connect, and re-login if possible, in the background. Even Outlook can do it. Not to mention flakey DSL or mobile connections that break your connection more frequently than that. It could be that your users are different. Looks like it, yes. Hardeding[1] stuff, you could get your soft faster just by specifying your exact arch (-march=native). Also for example -fomit-frame-pointer option for x86 can make short functions twice shorter and faster... Uh. Mentioning hardening and suggesting omit-frame-pointer in one sentence makes me shiver. No, I don't optimize for performance at that level, but rather go for portability and safety, if possible. Also, a quick Google search turns up this - maybe out of date - article: http://timetobleed.com/gcc-optimization-flag-makes-your-64bit-binary-fatter-and-slower/ Also, from http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Optimize-Options.html#Type-punning, it's unclear to me whether omit-frame-pointer will interfere with stack protection schemes, or which one takes precedence. I usually resort to trust in my fellow DDs to do the right things in this area... Kind regards, --Toni++ -- 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/20120604094820.ga18...@spruce.wiehl.oeko.net
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 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. Mind you, all these things are done to *prevent* the application from going to disk, and force it to stay in RAM. And that's exactly what I want. Second, session data MUST NOT be lost on reboot by default. Why not? I could not care less for the loss of session data every once in a while. People will log in again if their CMS backends really logged them out because of that, if anything, but session data is created for about every visitor, or spider, that hits the site(s), and will be forcefully cleaned up by cron-jobs, anyway. Not my code, so blame someone else. So even without /tmp, sysadmin should not put session data on tmpfs. I am unconvinced. You can store your session data wherever you like, but I prefer RAM. There're different admins, however... Yes, looks like it. No need to. You only need to add -pipe to your *FLAGS. You don't build software with default autotools flags (-g -O2) anyway, I guess. Well, usually I do, except that I usually only compile C friends, not write it. Kind regards, --Toni++ -- 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/20120603204546.gb18...@spruce.wiehl.oeko.net
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. Memcache? (0_o) Imho, that's even worse than store it on tmpfs, since memcache can just push your data off the cache and you'll get it lost even without reboot. I can think of session data in memcache only as some hack for load-balanced servers, but it requires careful memory configuration, otherwise users may find themselves logged off in the middle of a chat. Mind you, all these things are done to *prevent* the application from going to disk, and force it to stay in RAM. And that's exactly what I want. You already have a filesystem cache for that. Session data stays in RAM if it is used. But it does not get lost when inactive for a few hours. Why not? I could not care less for the loss of session data every once in a while. People will log in again if their CMS backends really logged them out because of that, if anything Plain users I've seen expect their session to stay alive for days. I.e. they have just checked the forum and then turned off PC. When tomorrow they turn it on they expect to be still logged in. They expect this to be true for everything (forums, blogs, web-email, etc). It's a disaster for them to be logged off, it takes hours to find a piece of paper where they wrote the password. They become angry if 10 minutes ago they were logged in and now they aren't, they don't care that I had to reboot the server. It could be that your users are different. but session data is created for about every visitor, or spider, that hits the site(s), and will be forcefully cleaned up by cron-jobs, anyway. Not my code, so blame someone else. Using tmpfs for session data was your decision, so you're to blame. :) I am unconvinced. You can store your session data wherever you like, but I prefer RAM. As usual it's up to you. You may have reasons for that. I'm just saying that having session data lost may be a bad thing, and having it lost by default is definitely a bad thing. No need to. You only need to add -pipe to your *FLAGS. You don't build software with default autotools flags (-g -O2) anyway, I guess. Well, usually I do, except that I usually only compile C friends, not write it. Oh, you're missing a lot of interesting things. :) Even skipping the Hardeding[1] stuff, you could get your soft faster just by specifying your exact arch (-march=native). Also for example -fomit-frame-pointer option for x86 can make short functions twice shorter and faster... [1] http://wiki.debian.org/Hardening -- Serge -- 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/CAOVenEqBwgGXFyYRfSy07jTxL04v=hv+6bjyuvcgnxvvds3...@mail.gmail.com
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 different admins, however... Which may be one of the reasons php saves,by default since Squeeze, sessions in: /var/lib/php5 Also, I would strongly suggest admins to separate each site's session storage into a different place, inaccessible from other sites (and best is even to chroot all sites running on the same server if possible). Thomas -- 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/4fcc32f0.7020...@debian.org
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 TMPTIME. Does it mean that there's no way we can mount /tmp to tmpfs because it breaks TMPTIME? -- Serge -- 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/CAOVenEqm2ZMcX6yM9njDGeX9xji_=syt7p4t1c2_qezwhbd...@mail.gmail.com
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 wishes to change the setting to keep files in /tmp even after reboot, you can’t use tmpfs, even if you don’t have enough space left. You can only print a warning message but not ignore the local configuration. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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 unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602115220.gc20...@spruce.wiehl.oeko.net
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 you assume an unexpected reboot, then all that data will be lost, forcing you to redownload these images. Couldn't /var/tmp serve this purpose better, if it's not exactly ephemeral data? (Like a temporary ISO created from on-disk content.) Kind regards Philipp Kern -- 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/20120602125603.ga11...@spike.0x539.de
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 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 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 different admins, however... Q: gcc writes small files in /tmp A: usually it does not, especially when used with -pipe option Changing all (generated?) Makefiles floating around out there, and getting the changes committed upstream to actually benefit from that is easier than using a tmpfs, of course. No need to. You only need to add -pipe to your *FLAGS. You don't build software with default autotools flags (-g -O2) anyway, I guess. -- Serge -- 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/CAOVenEpgq4vfwODL=fa+krvdeshavo4fcuzwspnyn4-myhf...@mail.gmail.com
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 /etc/default/rcS, which files in /tmp will be deleted. you to redownload these images. Couldn't /var/tmp serve this purpose better, if it's not exactly ephemeral data? (Like a temporary ISO created from on-disk content.) Since I’m not interested in filling my /var partition with tmp files (and so getting problems with databases or logs), /var/tmp is always a link to /tmp. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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 --bind the tmpfs on /tmp. 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? no... TMPTIME is currently meaningless (or effectively == 0) when /tmp is a tmpfs, that is simply an expected consequence of keeping /tmp in RAM. It could become meaningful if tmpfs on /tmp's contents were written to disk at shutdown then reloaded at boot when TMPTIME's value is !=0. What it does mean is that automatically changing a system over to /tmp on tmpfs was a bad idea both philosophically and because it could cause data lose; and that there should be a check of TMPTIME's value and the contents of /tmp before any automated mechanism changes to a tmpfs based /tmp, to mitigate the possibility of data loss. - Bruce -- 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/201206021602.24750.bms...@shaw.ca
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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 rootfs (which [...] may have lots of free space or very little). [...] consider tmpfs mounted on /tmp: the size specifies the total available space. Well, technically, we already guarantee that. The option TMP_OVERFLOW_LIMIT does. It mounts /tmp to tmpfs if there's too few free space there. But we can make it better. Idea: mount /tmp to tmpfs only when amount of free space in /tmp is fewer than amount of RAM. 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. Technical details: 0. fstab is already processed and /tmp was (or was not) mounted to a separate partition. 1. init-script cleans it (since it must clean it anyway) 2. and then compares `df /tmp/` with amount of RAM available. 3. If amount of RAM is larger it mounts /tmp to tmpfs 4. otherwise leaves /tmp as it is. This way we can guarantee that there will be as much space in /tmp as possible but *at least* as much as the amount of RAM available. Looks reasonable? Will that suit everyone? No. If /tmp is already mounted as a seperate partition then tmpfs should not be mounted. It might be neccessary to mount a tmpfs if the remaining size in /tmp is less than TMP_OVERFLOW_LIMIT. This case would only occur if the seperate /tmp filesystem is broken in that it can't be cleaned. With people doing stupid things like using just one partition you easily have 3TB free in / and therefore /tmp. Actualy having less space in /tmp than tmpfs would get would be quite rare. So tmpfs would basically never be used despite the benefits. Even non stupid setups can have lots of space in /. Specifically when you have /usr on / instead of a seperate partition. Having a few GB free there is quite reasonable. Still a tmpfs makes more sense. Even worse / can be read-only and then you always need a tmpfs for /tmp or a seperate partition. Or maybe I just like tmpfs and have configured my system to set the right options in /etc/default/tmpfs. You are completly ignoring that configuration. 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 too small to be usefull. For some user that would be 100MB, for others it is 100GB. Best I can come up with is that applications that need lots of space in /tmp, which are few, could check in postinst and give a debconf notice that /tmp should be resized according to /usr/share/doc/something/README.tmp-resize to at least xGiB. IMHO: this option should not break anything (and may even fix something) so it can be enabled by default. But it MUST be possible to disable it for those rare cases when admin intentionally left /tmp on a small partition. Your option would make all my systems unbootable since / is read-only, includes /usr and has some GB free space. MfG Goswin -- 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/87d35jkyvq.fsf@frosties.localnet
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 added. Looks reasonable? Will that suit everyone? No. :'-( If /tmp is already mounted as a seperate partition then tmpfs should not be mounted. Hm... Good point. Debian should not try to be smarter than admin. If admin specified a mountpoint for /tmp then it must be used whatever size it is. It might be neccessary to mount a tmpfs if the remaining size in /tmp is less than TMP_OVERFLOW_LIMIT. This case would only occur if the seperate /tmp filesystem is broken in that it can't be cleaned. Yes, I guess so. With people doing stupid things like using just one partition you easily have 3TB free in / and therefore /tmp. Actualy having less space in /tmp than tmpfs would get would be quite rare. This idea comes from an attempt to make everything work for small root partitions without breaking things that were working before. So tmpfs would basically never be used despite the benefits. Well, nobody named the benefits yet. Just the problems. There were a few attempts with some artificial test scripts, but no examples of real applications becoming faster with /tmp on tmpfs. And it's kind of pointless to change the defaults just to make some useless scripts faster. I could try finding a better solution if I knew the benefits. Or maybe I just like tmpfs and have configured my system to set the right options in /etc/default/tmpfs. You are completly ignoring that configuration. Or course, if you set the option it must be used. I was not suggesting to force that, just add one more option. For example in addition to RAMTMP=yes and RAMTMP=no add value RAMTMP=auto, and make it default value. So if you set RAMTMP=yes you'll get tmpfs (whatever you set in fstab). But if you don't set it you'll get auto behavior. In general your option assumes that you need the maximum amount of free space in /tmp. That is simply not true. It should solve all the tmpfs problems listed in the thread and break nothing. That was the goal. In most cases a small /tmp is just peachy. In *some* cases I would say. But I see nothing good in a small /tmp for default debian users. :) Because of this it is hard to set a minimum size where tmpfs would be too small to be usefull. For some user that would be 100MB, for others it is 100GB. I assume that it's still possible to change default options. I.e. you're free to change RAMTMP and TMP_SIZE to your needs. Best I can come up with is that applications that need lots of space in /tmp, which are few, could check in postinst and give a debconf notice that /tmp should be resized One of those few applications is tar, used by mc. I can't suggest a proper tmpfs size for it. ;) Your option would make all my systems unbootable since / is read-only, includes /usr and has some GB free space. 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 cleans it (since it must clean it anyway) 2. and checks `df /tmp/` for free space and partition 3.a. if RAMTMP == yes or RAMTMP == no then goto 4 3.b. if RAMTMP != auto then print a warning 3.c. if /tmp is not writable then RAMTMP=yes; goto 4 3.d. if /tmp is not on a root partition then RAMTMP=no; goto 4 3.e. if has_less_than_TMP_SIZE_free_space then RAMTMP=yes; goto 4 3.f. else RAMTMP == no 4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space then RAMTMP=yes 5. if RAMTMP == yes then mount /tmp to tmpfs Maintainer will probably write a better code. PS: Have you thought about mount-binding /tmp to /home/tmp for your read-only root systems? Or your /home partition isn't local? -- Serge -- 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/CAOVenEpy-zwzyKB7MYsGb=xCB6sBPAKD6uyDDVRF9GnrZ1=o...@mail.gmail.com
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 too small to be usefull. For some user that would be 100MB, for others it is 100GB. /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 this is not the meaning of /tmp, then rename it. Diskspace is cheap and easier to spare than my RAM. So, yes, if someone has one 3TB partition which is writeable, then /tmp belongs to disk not to RAM. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
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 cleans it (since it must clean it anyway) 2. and checks `df /tmp/` for free space and partition 3.a. if RAMTMP == yes or RAMTMP == no then goto 4 3.b. if RAMTMP != auto then print a warning 3.c. if /tmp is not writable then RAMTMP=yes; goto 4 3.d. if /tmp is not on a root partition then RAMTMP=no; goto 4 3.e. if has_less_than_TMP_SIZE_free_space then RAMTMP=yes; goto 4 3.f. else RAMTMP == no 4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space then RAMTMP=yes 5. if RAMTMP == yes then mount /tmp to tmpfs 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. Keeping track of whether /tmp was FS or tmpfs based when the system last shutdown could be used to skip all that since RAMTMP=yes implies TMPTIME=0 regardless of the setting in /etc/default/rcS. - Bruce -- 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/201206011934.18503.bms...@shaw.ca
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 of free space or very little). [...] consider tmpfs mounted on /tmp: the size specifies the total available space. Well, technically, we already guarantee that. The option TMP_OVERFLOW_LIMIT does. It mounts /tmp to tmpfs if there's too few free space there. But we can make it better. Idea: mount /tmp to tmpfs only when amount of free space in /tmp is fewer than amount of RAM. Technical details: 0. fstab is already processed and /tmp was (or was not) mounted to a separate partition. 1. init-script cleans it (since it must clean it anyway) 2. and then compares `df /tmp/` with amount of RAM available. 3. If amount of RAM is larger it mounts /tmp to tmpfs 4. otherwise leaves /tmp as it is. This way we can guarantee that there will be as much space in /tmp as possible but *at least* as much as the amount of RAM available. Looks reasonable? Will that suit everyone? IMHO: this option should not break anything (and may even fix something) so it can be enabled by default. But it MUST be possible to disable it for those rare cases when admin intentionally left /tmp on a small partition. -- Serge -- 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/caovenep6c0qf+k3olw_jlykza9qsgd8du4lbraayp1sm9wa...@mail.gmail.com
