Re: Summary: Moving /tmp to tmpfs makes it useless
Wouter Verhelst wou...@debian.org writes: On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote: On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote: Meanwhile, you've got a non-FHS directory on your system that is of no immediate use. Your later suggested /store as a user /tmp replacement is a non-FHS directory as well. No, you misunderstand. As a local sysadmin, I've installed systems with a large scratch space for users to use under a non-FHS directory. The FHS explicitly allows that. We have /scratch for that. Unlike /tmp the /scratch is not going to be cleaned on reboot. So it is more like /var/tmp. But I never said Debian should do the same. 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/87y5nb20bx.fsf@frosties.localnet
Re: Summary: Moving /tmp to tmpfs makes it useless
Henrique de Moraes Holschuh h...@debian.org writes: On Sun, 24 Jun 2012, Goswin von Brederlow wrote: Henrique de Moraes Holschuh h...@debian.org writes: I've read that some SSDs really *dislike* the way Linux does TRIM batching (or doesn't :p), so yes, it may well be that on most SSDs regular fstrim will do much better. I'm assuming this is due to fragmentation. With TRIM you get lots of small free chunks. With fstrim you get huge batches. AFAIK, it is related to trim requests not being of the same type as write/read requests (so you have to drain the queue of all in-flight commands or something), some SSDs being allergic to large batched trim requests while others are allergic to unbatched small trim requests, übershitty implementation of said command in SSDs (high latency, synchronous), etc. On top of whatever performance issues the Linux support for TRIM at the storage stack and filesystems might have. It may well have no fix. fstrim is not performance sensitive (people will run it when they have the time to wait for it to complete), so it doesn't matter if the SSD is very bad at TRIM and goes out for lunch for several seconds per trim request... Ahh, that makes more sense. I thought you ment normal read/write (without interleaved TRIM) would become slower. But if the disk doesn't defrag then won't it just be a matter of time for it to get slow with fstrim too? Any SSD worth its price has both the reserved flash and the background garbage collection systems required to defrag itself if left idle for long enough. But regular TRIMming lets it do a much better job. 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/87hatz1z5c.fsf@frosties.localnet
Re: Summary: Moving /tmp to tmpfs makes it useless
Henrique de Moraes Holschuh h...@debian.org writes: On Sun, 24 Jun 2012, Osamu Aoki wrote: On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote: Tollef Fog Heen wrote: On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. This was what I read elsewhere too. For now you shouldn't use discard option with SSDs, it's bad for performance. Better is to run fstrim periodically. Could you care to give us pointer to the rational behind your assertion? Better yet: just tell people to get their own answer, using bonie++. This is likely to be filesystem-specific, kernel version specific, storage-stack specific AND device-specific after all. I've read that some SSDs really *dislike* the way Linux does TRIM batching (or doesn't :p), so yes, it may well be that on most SSDs regular fstrim will do much better. I'm assuming this is due to fragmentation. With TRIM you get lots of small free chunks. With fstrim you get huge batches. But if the disk doesn't defrag then won't it just be a matter of time for it to get slow with fstrim too? 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/87fw9l7zyr.fsf@frosties.localnet
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, 24 Jun 2012, Goswin von Brederlow wrote: Henrique de Moraes Holschuh h...@debian.org writes: I've read that some SSDs really *dislike* the way Linux does TRIM batching (or doesn't :p), so yes, it may well be that on most SSDs regular fstrim will do much better. I'm assuming this is due to fragmentation. With TRIM you get lots of small free chunks. With fstrim you get huge batches. AFAIK, it is related to trim requests not being of the same type as write/read requests (so you have to drain the queue of all in-flight commands or something), some SSDs being allergic to large batched trim requests while others are allergic to unbatched small trim requests, übershitty implementation of said command in SSDs (high latency, synchronous), etc. On top of whatever performance issues the Linux support for TRIM at the storage stack and filesystems might have. It may well have no fix. fstrim is not performance sensitive (people will run it when they have the time to wait for it to complete), so it doesn't matter if the SSD is very bad at TRIM and goes out for lunch for several seconds per trim request... But if the disk doesn't defrag then won't it just be a matter of time for it to get slow with fstrim too? Any SSD worth its price has both the reserved flash and the background garbage collection systems required to defrag itself if left idle for long enough. But regular TRIMming lets it do a much better job. -- 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/20120624141340.ga24...@khazad-dum.debian.net
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote: On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote: So most of your Debian systems have several users working at the same time on the same system? Okay, then you have a different user base. webserver. Sorry, I ignored servers. I don’t think that anyone will install a server with a default installation because you have more special cases (separate database partition, separate mailbox partition, etc.). I still think that the SSD problem is not a valid concern as long as we don’t have solutions for /var and log daemons. There is more traffic in /var than in /tmp. Yes, /var produces changes to storage, too, but that doesn't mean we shouldn't optimize /tmp because we can't optimize /var. That makes no sense. But if you move the /tmp access away (see below), then you don’t need tmpfs at all. I'm not saying we should optimize for SSDs. I'm just saying that storing on tmpfs is beneficial for SSDs. See below. [/ramtmp not a good idea] Well, why? Because it would end up being a directory that nearly nobody would use directly. Those who want to use a ramdisk will just remove that directory (or make it a symlink) and mount /tmp on tmpfs instead, and those who don't want to use it will probably just ignore it. I don’t think so. Having a disk based /tmp that gets cleaned after reboots and having a ramdisk /ramtmp will give you the choice which directory you want to use for a special application. Your video encoder example could certainly use /ramtmp, even if you have to patch the encoder in Debian to do so. The temporary video files of the web browser can stay in /tmp, as well as big powerpoint temporary files of libreoffice. And I don’t think that most user only want one solution. Also, if deciding on a reasonable default for /tmp is difficult, think about deciding on a reasonable default for individual packages. That's going to be even harder. Sometimes maybe. But you will certainly get some hundred of megabytes of tmpfs space. So if you know that your temporary file will be smaller, you can use /ramtmp. Besides we can look for other places to use tmpfs. What about /var/lib/amavis/tmp? The initscript could create a tmpfs. Meanwhile, you've got a non-FHS directory on your system that is of no immediate use. Your later suggested /store as a user /tmp replacement is a non-FHS directory as well. /tmp has always been about 10-20GB big, because I expect users to store big temporary images in /tmp. I won’t get this with tmpfs and I would have to train the users to change their behaviour. I believe this is part of our disagreement: I don't think system-wide directories are meant for users to use directly. In other words, I don't think users should put large downloads in /tmp; instead, they should put Now this thread is the first time someone mentions that /tmp should not be used by users but is only for system services. I don’t know of any documentation to support this claim. On the contrary all documentation about Unix/Linux I know say that /tmp is for all temporary files. But let’s say, /tmp is only for system services. Temporary user files belong to $HOME/tmp (which would be a special case in Debian only). So besides from teaching all users to not use /tmp, we need a cleaning job for $HOME/tmp and have to patch all software (browser, libreoffice, libpam-tmp, etc) to use the new tmp. But then most of your examples for tmpfs will be void because no user will use it. Your video encoder is a user application, so the temporary statistic file will go to $HOME/tmp, not to /tmp. And if you say that noone will use a combination of /tmp and /ramtmp, why do you think that someone will suddenly use a combination of /tmp (tmpfs) and $HOME/tmp? So I still think that my /ramtmp additional to /tmp are for now the best of both worlds without the risk of breaking applications and user expectations. 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: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote: On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote: Meanwhile, you've got a non-FHS directory on your system that is of no immediate use. Your later suggested /store as a user /tmp replacement is a non-FHS directory as well. No, you misunderstand. As a local sysadmin, I've installed systems with a large scratch space for users to use under a non-FHS directory. The FHS explicitly allows that. But I never said Debian should do the same. /tmp has always been about 10-20GB big, because I expect users to store big temporary images in /tmp. I won’t get this with tmpfs and I would have to train the users to change their behaviour. I believe this is part of our disagreement: I don't think system-wide directories are meant for users to use directly. In other words, I don't think users should put large downloads in /tmp; instead, they should put Now this thread is the first time someone mentions that /tmp should not be used by users but is only for system services. I don’t know of any documentation to support this claim. Neither do I :-) I *personally* think /tmp should not be used for user data. It's not the best place for that, for various reasons (impact on the system, lack of privacy, possible namespace collisions, ...). But I'm not going to say that people should not use it for that. It's perfectly fine if you want to do that, it's just not a very good idea. IMO. [...] -- 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/20120625001100.gc31...@grep.be
Re: Summary: Moving /tmp to tmpfs makes it useless
Tollef Fog Heen wrote: On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. For now you shouldn't use discard option with SSDs, it's bad for performance. Better is to run fstrim periodically. -- 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/20120623150015.GA24345@lisko
Re: Summary: Moving /tmp to tmpfs makes it useless
On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote: On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote: Maybe, but we are talking about defaults. Please correct me, but I think that most Debian systems are in some way single user systems. Not in my experience. So most of your Debian systems have several users working at the same time on the same system? Okay, then you have a different user base. webserver. Additionally, in $DAYJOB I do indeed maintain a number of systems where users log in remotely (through VNC and/or NX) and work on the system, with several people logged in at the same time. [...] I agree, but only if your tmpfs is big enough to hold the file. Ripping DVDs or BDs will exceed any tmpfs limit on most systems. Not necessarily. Ffmpeg's two-pass video encoding uses a temporary file to which it writes statistics about the video file being processed Ah, thank you for the explanation, but to optimize the encoder in the second pass. This statistics file contains data such as at time index X, Y% of the image changes in ASCII form, and hence need not be much larger than some tens of megabytes for a full-sized DVD. if the file is only about some tens of megabytes, do you really gain so much speed? Yes. Filesystems and disks are very good at optimizing sequential reads from a single (large) file if no other disk access happens at the same time. However, if you write to another file during that sequential access, you take a performance hit, since now there's more than just one file. It's not about the size of the file as opposed to about having additional disk access interfering with optimizations. Having said that, this is besides the point, really. The point is that yes, tmpfs is really faster. I gave you a few examples where this is true, but the examples aren't really the point; the fact that tmpfs is indeed faster, is. You can maybe convince me that in one or two specific use cases it won't matter much, but not that it won't matter as a whole. RAM is faster than disk. That's a fact. Therefore, tmpfs will be faster than disk, too, and that's an advantage. Can we stop talking about specific use cases now? Nobody disagrees that RAM is faster than disk, but I hope you don’t disagree as well that most people will have more disk space than RAM. That leads us to the crux of the discussion: we are both right. You are right in that /tmp on disk lowers the chance of /tmp running out of space, which is a real problem. I, and others arguing in favour of tmpfs, are right that placing /tmp on tmpfs will speed up things and (if not using any swap space) will reduce usage of an SSD, both of which are real improvements. I still think that the SSD problem is not a valid concern as long as we don’t have solutions for /var and log daemons. There is more traffic in /var than in /tmp. You're letting the perfect be the enemy of the good, then. Yes, /var produces changes to storage, too, but that doesn't mean we shouldn't optimize /tmp because we can't optimize /var. That makes no sense. If we really want to optimize for SSDs we should do something like: - /tmp and /var/tmp on tmpfs - no local logging or the possibility to enter a log server - patching any applications like iceweasel to store their cache on a tmpfs - running trim daemon for discard (maybe) I'm not saying we should optimize for SSDs. I'm just saying that storing on tmpfs is beneficial for SSDs. I'm not trying to steer the discussion towards SSDs or anything; I just think that tmpfs is a good option for /tmp, for various reasons. That we can get the same effects with other measures is great, but of no relevance for a discussion about tmpfs. [...] The question is: what matters most? To me, the performance improvements of tmpfs are significant enough to warrant making it the default. Clearly, you disagree. Yes, because the performance improvements will only get you speed but risk breakage of the application because /tmp is now smaller than it was before tmpfs times. On the other hand disk /tmp will make some things slower, but in the end it is safer. And I think users understand the problem of a full disk much easier than how to expand a full ram disk. Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. While I think a compromise would be wonderful, I don't think this is it. Additionally, I don't think this is technically and aesthetically a very good solution. Well, why? Because it would end up
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote: Tollef Fog Heen wrote: On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. This was what I read elsewhere too. For now you shouldn't use discard option with SSDs, it's bad for performance. Better is to run fstrim periodically. Could you care to give us pointer to the rational behind your assertion? Regards, Osamu -- 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/20120623174124.GA8582@goofy.localdomain
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, 24 Jun 2012, Osamu Aoki wrote: On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote: Tollef Fog Heen wrote: On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. This was what I read elsewhere too. For now you shouldn't use discard option with SSDs, it's bad for performance. Better is to run fstrim periodically. Could you care to give us pointer to the rational behind your assertion? Better yet: just tell people to get their own answer, using bonie++. This is likely to be filesystem-specific, kernel version specific, storage-stack specific AND device-specific after all. I've read that some SSDs really *dislike* the way Linux does TRIM batching (or doesn't :p), so yes, it may well be that on most SSDs regular fstrim will do much better. -- 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/20120624005126.gd20...@khazad-dum.debian.net
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/19 Wouter Verhelst wrote: That's not true. Only applications, that are limited by /tmp speed will become faster then. Do you know such applications? Any application which performs I/O anywhere has a chance of being limited by it. In theory. But do you know any applications actually using that chance? If you write to /tmp on disk and someone or something calls sync at precisely the wrong moment, you're stuck, and your performance suffers. I don't know any examples. Can you suggest one? I mean, what should be those two programs, one of which calls sync while another writing large data to /tmp so I could measure the performance difference? I'm not saying the speedup will be extreme, but it will be there, and (cumulated over loads of programs using /tmp) it will be significant enough to be noticeable. If it is noticeable it's great! What'd I do to notice it on my system? Can I provide a use case where this will matter? Not necessarily. But then, can you provide a use case where this will *not* matter? Really? Yes. Everything. Oh, interesting. You have the data to back that claim up? Every test I posted to this list. :) You make it sound as if those three are the only uses of /tmp. That's just not true. I just named the most popular ones for regular users. - The nbd test suite stores fairly large files in $TMPDIR on which it then runs nbd-server How much faster it becomes with tmpfs? Can you do e.g. 5 tests in a row with tmpfs and then 5 tests without it to compare the difference? If it can really benefit from tmpfs, then, it's good, it would be the first real-world program to use tmpfs so far... Also, how large tmpfs does it need? Is it still faster with tmpfs if tmpfs gets swapped? (set cpufreq governor to performance when doing the test, and stop `*cron` if tests are too long) - Any data transformation or filtering which needs to be done in multiple passes over a file would use a temporary file for intermediate results That's a theory. Neither you nor I can answer the question of how much faster such any data transformation will become. Multi-pass video transcoding is an example of this, and which (depending on the codecs used and the hardware on which it runs) could certainly be I/O bound. It's CPU-bound unless you know some *really* fast codec that I'm not aware of. :) Or do you have some example that I can run and see it becoming faster with tmpfs myself? - using mc on a tar.gz which was compressed with --fast It could be. Is it just a guess, or have you checked it on some real-world archives? I.e. my test with linux-kernel archive have not confirmed that. The point is that neither you nor I can reasonably be expected to list all possible uses of /tmp It's not the point. The point is to find those uses that are limited by /tmp I/O speed. and that RAM is faster than disk, so that when you access a tmpfs you're going to be somewhat faster than when you access a disk-backed filesystem No. That's a theory, and it's wrong. :) RAM is faster than disk, so accessing a tmpfs MAY be faster IF you're limited by the I/O speed. Theories can be wrong, that's why I always ask for examples, tests... Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea to use tmpfs without swap, since it would be too small and may even trigger OOM killer. When is it good to use tmpfs then? ;) I never used tmpfs on a system with swap, and I've not often seen the OOM killer start doing its job. My current machine has 4GiB of RAM, which seems to be more than enough. Heh. You're saying that tmpfs is not too bad for you. But it does not automatically make it good for you. :) User cannot break the system filling /tmp on disk. But he can do that if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of failure for servers. No, that's not true. The real danger in filling up /tmp is not that other processes can't write temporary files anymore (causing a minority of processes to hang or die; those who just happen to need temporary storage at that point in time), but that no process can write any file anymore (causing a significant majority of processes to hang or die). Hrm... But there're no other directories on a root partition that user can write to. If you mean that /tmp on tmpfs prevents /var or /home from being filled then it's not true either. Putting /tmp on tmpfs will force people to use /var/tmp or /home for large files and will (not can, but will, since /var/tmp is not cleaned) eventually fill those partition, which is exactly what you were trying to prevent. :) Now whether that advantage outweighs the disadvantages you've outlined is something we can talk about. However, whether RAM is faster than disk isn't; Why are you limiting it to either yes or no? There're other options. It's not about RAM is faster than disk. It's about whether there're any programs becoming noticeably faster because RAM is faster than disk.
Re: Summary: Moving /tmp to tmpfs makes it useless
On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote: Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. Why not use /run instead? Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Fri, 22 Jun 2012, Andrei POPESCU wrote: On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote: Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. Why not use /run instead? Feel free to add a *mountpoint* at /run/tmp and provide a second tmpfs there[1]. But if you do that, we'd have /tmp, /run/tmp, and /var/tmp so to me it just looks like a mess... Well, /var/tmp is always disk-backed and it is supposed to last across reboots, and files there should last for a while before any automated cleaning. It is written nowhere that you can leave large files in there, though, but it is not supposed to be too space-constrained. /run/tmp might be defined from the get go to be tmpfs, and not some place you should expect to be able to abuse (i.e. can't be automatically used to unpack large amounts of crap, host the tile cache of a pixel editor or the browser's cache, etc). What good would it do, I don't know: you'd need to set TMPDIR=/run/tmp to use it anyway, so might as well just do it to /tmp... [1] Should you fill /run or cause a filename colision, very bad things can happen. You don't use /var/lock and /var/run as a general dumping ground for random crap, and the same rule applies to /run. -- 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/20120622192819.gc32...@khazad-dum.debian.net
Re: Summary: Moving /tmp to tmpfs makes it useless
On Wed, Jun 20, 2012 at 03:18:55PM +0200, Stephan Seitz wrote: On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote: If you write to /tmp on disk and someone or something calls sync at precisely the wrong moment, you're stuck, and your performance suffers. Not so with tmpfs. Maybe, but we are talking about defaults. Please correct me, but I think that most Debian systems are in some way single user systems. Not in my experience. I'm not saying the speedup will be extreme, but it will be there, and (cumulated over loads of programs using /tmp) it will be significant enough to be noticeable. If you train the user to keep away from /tmp, because it may be too small with tmpfs, how much programs will use it then? This argument is circular. If you train the user to keep away from /tmp, because it may be too slow without tmpfs, how many programs will use it then? - Any data transformation or filtering which needs to be done in multiple passes over a file would use a temporary file for intermediate results, which it then reads in again for the next pass. Multi-pass video transcoding is an example of this, and which (depending on the codecs used and the hardware on which it runs) could certainly be I/O bound. I agree, but only if your tmpfs is big enough to hold the file. Ripping DVDs or BDs will exceed any tmpfs limit on most systems. Not necessarily. Ffmpeg's two-pass video encoding uses a temporary file to which it writes statistics about the video file being processed (mainly data about how fast the image moves, etc), which it can then use to optimize the encoder in the second pass. This statistics file contains data such as at time index X, Y% of the image changes in ASCII form, and hence need not be much larger than some tens of megabytes for a full-sized DVD. The _output_ of the encoder (the encoded MPEG file) in the first pass is irrelevant, and can in fact be thrown away. That's the whole point of doing two-pass encoding. So that leaves you with reading a whole lot of data from disk, and writing a temporary file to RAM. The point is that neither you nor I can reasonably be expected to list all possible uses of /tmp; and that RAM is faster than disk, so that when you access a tmpfs you're going to be somewhat faster than when you access a disk-backed filesystem, at least until you start swapping (if not longer). Nobody disagrees that RAM is faster than disk, but I hope you don’t disagree as well that most people will have more disk space than RAM. That leads us to the crux of the discussion: we are both right. You are right in that /tmp on disk lowers the chance of /tmp running out of space, which is a real problem. I, and others arguing in favour of tmpfs, are right that placing /tmp on tmpfs will speed up things and (if not using any swap space) will reduce usage of an SSD, both of which are real improvements. The question is: what matters most? To me, the performance improvements of tmpfs are significant enough to warrant making it the default. Clearly, you disagree. Now whether that advantage outweighs the disadvantages you've outlined is something we can talk about. However, whether RAM is faster than disk Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. While I think a compromise would be wonderful, I don't think this is it. Additionally, I don't think this is technically and aesthetically a very good solution. No, that's not true. The real danger in filling up /tmp is not that other processes can't write temporary files anymore (causing a minority of processes to hang or die; those who just happen to need temporary storage at that point in time), but that no process can write any file anymore (causing a significant majority of processes to hang or die). But this will only happen if your /tmp is not a separate partition. Yes; but if you're going to make /tmp be a separate partition, then your argument that there's more space on disk doesn't really hold anymore, either, since now /tmp is much much smaller than your disk (I've never seen a system with a separate partition for /tmp use more than a few gigs for that partition). And it can happen with /var as well. I’ve seen programs logging so fast that /var had no space left breaking the logging and the database. Absolutely, I'm not contesting that (in fact, I've recently had a very similar situation at a customer). But this discussion is not about /var, it's about /tmp. -- The volume of a pizza of thickness a
Re: Summary: Moving /tmp to tmpfs makes it useless
On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote: Maybe, but we are talking about defaults. Please correct me, but I think that most Debian systems are in some way single user systems. Not in my experience. So most of your Debian systems have several users working at the same time on the same system? Okay, then you have a different user base. If you train the user to keep away from /tmp, because it may be too small with tmpfs, how much programs will use it then? This argument is circular. I beg to disagree. If you train the user to keep away from /tmp, because it may be too slow without tmpfs, how many programs will use it then? But the disk will not be so slow to break applications like they would if you run out of disk space. So we weight a time advantage against an enough space advantage. And since the user don’t know about tmpfs they won’t think that there /tmp is slow. Besides disk /tmp is still faster than NFS /home. ;-) I agree, but only if your tmpfs is big enough to hold the file. Ripping DVDs or BDs will exceed any tmpfs limit on most systems. Not necessarily. Ffmpeg's two-pass video encoding uses a temporary file to which it writes statistics about the video file being processed Ah, thank you for the explanation, but to optimize the encoder in the second pass. This statistics file contains data such as at time index X, Y% of the image changes in ASCII form, and hence need not be much larger than some tens of megabytes for a full-sized DVD. if the file is only about some tens of megabytes, do you really gain so much speed? Nobody disagrees that RAM is faster than disk, but I hope you don’t disagree as well that most people will have more disk space than RAM. That leads us to the crux of the discussion: we are both right. You are right in that /tmp on disk lowers the chance of /tmp running out of space, which is a real problem. I, and others arguing in favour of tmpfs, are right that placing /tmp on tmpfs will speed up things and (if not using any swap space) will reduce usage of an SSD, both of which are real improvements. I still think that the SSD problem is not a valid concern as long as we don’t have solutions for /var and log daemons. There is more traffic in /var than in /tmp. If we really want to optimize for SSDs we should do something like: - /tmp and /var/tmp on tmpfs - no local logging or the possibility to enter a log server - patching any applications like iceweasel to store their cache on a tmpfs - running trim daemon for discard (maybe) This could be part of an enhanced laptop mode because it would safe battery time for normal disks as well. The question is: what matters most? To me, the performance improvements of tmpfs are significant enough to warrant making it the default. Clearly, you disagree. Yes, because the performance improvements will only get you speed but risk breakage of the application because /tmp is now smaller than it was before tmpfs times. On the other hand disk /tmp will make some things slower, but in the end it is safer. And I think users understand the problem of a full disk much easier than how to expand a full ram disk. Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. While I think a compromise would be wonderful, I don't think this is it. Additionally, I don't think this is technically and aesthetically a very good solution. Well, why? Other suggestions were to write daemons monitoring tmpfs and increasing it if necessary together with swap space. Or writing a daemon to blend tmpfs and disk together. Besides that these daemons must be written and tested first it sounds much to complicated to me. With my suggestion you have both worlds available without manual configuration by the user, and we can encourage our users to test it and report to us if they find it useful or not. I see the advantages of tmpfs but I wouldn’t replace my disk tmp with it, only have it as alternative. But this will only happen if your /tmp is not a separate partition. Yes; but if you're going to make /tmp be a separate partition, then your argument that there's more space on disk doesn't really hold anymore, either, since now /tmp is much much smaller than your disk (I've never seen a system with a separate partition for /tmp use more than a few gigs for that partition). While you are right that /tmp on a separate partition is smaller than the disk, you are wrong (at least in my cases) that tmpfs would now be bigger than disk /tmp. My smallest
Re: Summary: Moving /tmp to tmpfs makes it useless
Dnia 2012-06-21, czw o godzinie 09:06 +0200, Wouter Verhelst pisze: [ cut ] Yes; but if you're going to make /tmp be a separate partition, then your argument that there's more space on disk doesn't really hold anymore, either, since now /tmp is much much smaller than your disk (I've never seen a system with a separate partition for /tmp use more than a few gigs for that partition). All my computers have 1 user. On all my non-laptop machines I have /tmp as separate partitions which sizes are varying between 9GB and almost 20GB. I try to at least have enough space on /tmp to be able to store both DVD image (iso9660) and data for it. I have discovered moving /tmp to tmpfs on my laptop. I was making backup and got message that I run out of space in /tmp. After discovering the reason I have just changed my scripts to use /var/tmp instead of /tmp. From this discussion it looks like there is no easy compromise. As a (power) user I would prefer to have debconf question during upgrade, e.g. We are proposing for you to move /tmp to use tmpfs. On your system you have X MB of RAM which means that your tmpfs will have Y MB. You can also leave /tmp as is to use hard disk which will be slower, can cause SSD wear-out, but will allow for storing large files. Best regards. -- Tomasz Rybak tomasz.ry...@post.pl GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Re: Summary: Moving /tmp to tmpfs makes it useless
Stephan Seitz stse+deb...@fsing.rootsland.net writes: On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote: Maybe, but we are talking about defaults. Please correct me, but I think that most Debian systems are in some way single user systems. Not in my experience. So most of your Debian systems have several users working at the same time on the same system? Okay, then you have a different user base. Far and away the majority of my Debian systems are zero-user systems. They're servers. Of the remaining ones, I think I have about 10x as many multiuser systems as single-user systems. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87k3z0ad31@windlord.stanford.edu
Re: Summary: Moving /tmp to tmpfs makes it useless
On Wed, Jun 20, 2012 at 09:08:51PM +0200, Carlos Alberto Lopez Perez wrote: On 20/06/12 15:18, Stephan Seitz wrote: Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. I really think this is the way to go :) As do I. Not because I think diskbased /tmp is something worth keeping (on the contrary I consider tmpfs-based /tmp to be superior), but because I think it'd be impossible to convince some people that /tmp isn't a random dumping ground for anything and everything. I think that having a tmpfs file system, and mandating that long-term all software packaged for Debian -- where possible -- except in special cases, and leave /tmp primarily as a dumping ground for the user (If it wasn't for NFS *shudder* I'd advocate /home/user/tmp for this purpose instead). Regards: DAvid -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- 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/20120621202003.gc25...@suiko.acc.umu.se
Re: Summary: Moving /tmp to tmpfs makes it useless
On Thu, Jun 21, 2012 at 10:20:03PM +0200, David Weinehall wrote: because I think it'd be impossible to convince some people that /tmp isn't a random dumping ground for anything and everything. But what is /tmp for you? Since my first Unix experience in the 90s, /tmp was always the local disk for temporary things. Yes, it is limited by the disk size. At university your $HOME was a NFS share (and I don’t know what you have against NFS for a shared filesystem; do yo prefer CIFS?), /tmp was always local like swap. If /tmp isn’t a „dumping ground für anything and everything” as long as there is enough space, what directory is more fitting? /tmp is cleaned at every reboot (configurable by TMPTIME), so a user doesn’t have to worry about it. Do you want something similiar for your /home/user/tmp? Should we now have different definitions of „temporary file”? 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: Summary: Moving /tmp to tmpfs makes it useless
On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote: If you write to /tmp on disk and someone or something calls sync at precisely the wrong moment, you're stuck, and your performance suffers. Not so with tmpfs. Maybe, but we are talking about defaults. Please correct me, but I think that most Debian systems are in some way single user systems. I'm not saying the speedup will be extreme, but it will be there, and (cumulated over loads of programs using /tmp) it will be significant enough to be noticeable. If you train the user to keep away from /tmp, because it may be too small with tmpfs, how much programs will use it then? - Any data transformation or filtering which needs to be done in multiple passes over a file would use a temporary file for intermediate results, which it then reads in again for the next pass. Multi-pass video transcoding is an example of this, and which (depending on the codecs used and the hardware on which it runs) could certainly be I/O bound. I agree, but only if your tmpfs is big enough to hold the file. Ripping DVDs or BDs will exceed any tmpfs limit on most systems. The point is that neither you nor I can reasonably be expected to list all possible uses of /tmp; and that RAM is faster than disk, so that when you access a tmpfs you're going to be somewhat faster than when you access a disk-backed filesystem, at least until you start swapping (if not longer). Nobody disagrees that RAM is faster than disk, but I hope you don’t disagree as well that most people will have more disk space than RAM. Now whether that advantage outweighs the disadvantages you've outlined is something we can talk about. However, whether RAM is faster than disk Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. No, that's not true. The real danger in filling up /tmp is not that other processes can't write temporary files anymore (causing a minority of processes to hang or die; those who just happen to need temporary storage at that point in time), but that no process can write any file anymore (causing a significant majority of processes to hang or die). But this will only happen if your /tmp is not a separate partition. And it can happen with /var as well. I’ve seen programs logging so fast that /var had no space left breaking the logging and the database. We can now start another discussion what should be the best partition layout for a default installation, but /tmp is not the only problem. And /var/tmp exists as well for everyone writeable. 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: Summary: Moving /tmp to tmpfs makes it useless
On 20/06/12 15:18, Stephan Seitz wrote: Fine let’s talk. Why can’t we find a compromise? Additional to our disk /tmp we create a /ramtmp (so the name suggests that this tmp is a ramdisk) with tmpfs. This should be doable in time for Wheezy. The release notes should mention it. And those who wish can patch their programs to use the ramdisk if they think their program uses only small temporary files. In this way, we get some data and experience. And we have both worlds. /tmp on disk for even large temporary files and /ramtmp as fast ramdisk. I really think this is the way to go :) -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Re: Summary: Moving /tmp to tmpfs makes it useless
Wouter Verhelst wou...@debian.org writes: On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote: User cannot break the system filling /tmp on disk. But he can do that if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of failure for servers. No, that's not true. The real danger in filling up /tmp is not that other processes can't write temporary files anymore (causing a minority of processes to hang or die; those who just happen to need temporary storage at that point in time), but that no process can write any file anymore (causing a significant majority of processes to hang or die). So tmpfs for /tmp increases the chance of accidentally filling up /tmp and causing a moderate failure but prevents malicious filling up of /tmp to cause wide spread failure. :) 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/87ipend1nb.fsf@frosties.localnet
Re: Summary: Moving /tmp to tmpfs makes it useless
On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote: 2012/6/10 Wouter Verhelst wrote: A lot of people (including you) said that tmpfs makes things faster. But there were no examples of popular use-cases becoming faster because of /tmp on tmpfs, so I had nothing to quote. You're not even trying. if tmpfs is faster than (say) ext4, then anything which uses /tmp will obviously speed up. That's not true. Only applications, that are limited by /tmp speed will become faster then. Do you know such applications? Any application which performs I/O anywhere has a chance of being limited by it. If you write to /tmp on disk and someone or something calls sync at precisely the wrong moment, you're stuck, and your performance suffers. Not so with tmpfs. I'm not saying the speedup will be extreme, but it will be there, and (cumulated over loads of programs using /tmp) it will be significant enough to be noticeable. Can I provide a use case where this will matter? Not necessarily. But then, can you provide a use case where this will *not* matter? Really? Yes. Everything. Oh, interesting. You have the data to back that claim up? Every popular /tmp usage that most users expect to work is limited either by CPU (gcc compiling) I don't think compiling C code has been CPU bound since before I was born (and I was born in the late 70s, so that's quite a while). C++ is a different matter, but still. or by network speed (browser or flash temporaries), or is just too fast already (bash heredoc). You make it sound as if those three are the only uses of /tmp. That's just not true. Here are some other real-world uses of /tmp, which are (or can be) I/O bound and where the size is significant enough that it makes a difference: - The nbd test suite stores fairly large files in $TMPDIR on which it then runs nbd-server (yes, maybe that's cheating since I maintain nbd; still, it's been that way for quite some time now, certainly since before tmpfs was the default). - Any data transformation or filtering which needs to be done in multiple passes over a file would use a temporary file for intermediate results, which it then reads in again for the next pass. Multi-pass video transcoding is an example of this, and which (depending on the codecs used and the hardware on which it runs) could certainly be I/O bound. - using mc on a tar.gz which was compressed with --fast I could probably go on if I really wanted to, but that's fairly boring. The point is that neither you nor I can reasonably be expected to list all possible uses of /tmp; and that RAM is faster than disk, so that when you access a tmpfs you're going to be somewhat faster than when you access a disk-backed filesystem, at least until you start swapping (if not longer). Now whether that advantage outweighs the disadvantages you've outlined is something we can talk about. However, whether RAM is faster than disk isn't; and the fact that avoiding disk access will result in speedups, no matter how small, isn't up for discussion either. [...] Nobody could provide examples or numbers of how much /tmp on tmpfs reduces amount of writes, and tests showed that tmpfs+swap may even increase amount of writes (hence not always good for SSD), True, but then swapping to an SSD is the best idea since 640kB is enough for everyone :-) Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea to use tmpfs without swap, since it would be too small and may even trigger OOM killer. When is it good to use tmpfs then? ;) I never used tmpfs on a system with swap, and I've not often seen the OOM killer start doing its job. My current machine has 4GiB of RAM, which seems to be more than enough. The only exception was when I was trying to run one VM too many, which then tried to eat up 110% of my RAM, but that wasn't a good idea in any case. [...] tmpfs does not have 5% overflow safety, Because it doesn't need it. The 5% overflow safety exists for two reasons: - to avoid excessive fragmentation (which is not relevant for tmpfs) - to allow you to clean up when the filesystem does fill up. You missed one more reason. When user fills the entire /tmp on disk, it does not break system services, since root can still use those 5%. Most system services do not run as root, so that's not a real advantage. However, even if they did, your statement is still wrong: User cannot break the system filling /tmp on disk. But he can do that if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of failure for servers. No, that's not true. The real danger in filling up /tmp is not that other processes can't write temporary files anymore (causing a minority of processes to hang or die; those who just happen to need temporary storage at that point in time), but that no process can write any file anymore (causing a significant majority of processes to hang or die). -- The volume of a pizza of thickness a
Re: Summary: Moving /tmp to tmpfs makes it useless
Wouter Verhelst wrote: I don't think compiling C code has been CPU bound since before I was born (and I was born in the late 70s, so that's quite a while). C++ is a different matter, but still. Bullshit. GCC uses a lot of CPU unless you compile without optimization, and is surprisingly slow even if you do (nowhere near linear disk access speed). -- 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/1340068942.23020.5.camel@glyph.nonexistent.invalid
Re: Summary: Moving /tmp to tmpfs makes it useless
Le mercredi 13 juin 2012 à 04:14 +0300, Serge a écrit : Yes. Everything. Every popular /tmp usage that most users expect to work is limited either by CPU (gcc compiling) or by network speed (browser or flash temporaries), or is just too fast already (bash heredoc). So moving /tmp to tmpfs does not make them faster, but can break them instead (if there's not enough space to store a streamed video, for example). You should really back up claims such as “GCC is CPU-bound” with data. Because it sounds to me that when building with make -j8 on a fast multi-core system, you will hit the IOPS limit of a rotating drive very quickly. (And please stop with this streamed video red herring. We do not choose solutions based on bugs in proprietary applications, especially when no actual solution will really work around that bug - you will always find a case when a video fills your disk.) -- .''`. 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/1339572149.4245.348.camel@pi0307572
Re: Summary: Moving /tmp to tmpfs makes it useless
On Wed, 2012-06-13 at 09:22 +0200, Josselin Mouette wrote: Le mercredi 13 juin 2012 à 04:14 +0300, Serge a écrit : Yes. Everything. Every popular /tmp usage that most users expect to work is limited either by CPU (gcc compiling) or by network speed (browser or flash temporaries), or is just too fast already (bash heredoc). So moving /tmp to tmpfs does not make them faster, but can break them instead (if there's not enough space to store a streamed video, for example). You should really back up claims such as “GCC is CPU-bound” with data. Because it sounds to me that when building with make -j8 on a fast multi-core system, you will hit the IOPS limit of a rotating drive very quickly. [...] It's fine with a local disk and enough RAM for a decent disk cache. (NFS is another matter.) Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Wouter Verhelst wrote: A lot of people (including you) said that tmpfs makes things faster. But there were no examples of popular use-cases becoming faster because of /tmp on tmpfs, so I had nothing to quote. You're not even trying. if tmpfs is faster than (say) ext4, then anything which uses /tmp will obviously speed up. That's not true. Only applications, that are limited by /tmp speed will become faster then. Do you know such applications? Can I provide a use case where this will matter? Not necessarily. But then, can you provide a use case where this will *not* matter? Really? Yes. Everything. Every popular /tmp usage that most users expect to work is limited either by CPU (gcc compiling) or by network speed (browser or flash temporaries), or is just too fast already (bash heredoc). So moving /tmp to tmpfs does not make them faster, but can break them instead (if there's not enough space to store a streamed video, for example). Nobody could provide examples or numbers of how much /tmp on tmpfs reduces amount of writes, and tests showed that tmpfs+swap may even increase amount of writes (hence not always good for SSD), True, but then swapping to an SSD is the best idea since 640kB is enough for everyone :-) Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea to use tmpfs without swap, since it would be too small and may even trigger OOM killer. When is it good to use tmpfs then? ;) tmpfs does not have 5% overflow safety, Because it doesn't need it. The 5% overflow safety exists for two reasons: - to avoid excessive fragmentation (which is not relevant for tmpfs) - to allow you to clean up when the filesystem does fill up. You missed one more reason. When user fills the entire /tmp on disk, it does not break system services, since root can still use those 5%. User cannot break the system filling /tmp on disk. But he can do that if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of failure for servers. -- 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/CAOVenErV3+M2eMsQLmgR3aYJxKhY2Y3JsTLUz=k70C=sf52...@mail.gmail.com
Re: Summary: Moving /tmp to tmpfs makes it useless
Le dimanche 10 juin 2012 à 01:51 +0300, Serge a écrit : Some people asked for a thread summary. So here it is. /tmp on tmpfs is good quotes == No real quotes here. So much for a thread summary. -- .''`. 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/1339399239.4245.171.camel@pi0307572
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote: Some people asked for a thread summary. So here it is. [Lots of drivel, including thoroughly debunked statements, snipped. Seriously, can't you even read what's written to you? Sorry for being angry, but there's a limit to how many times you can have folks explain the basics of page cache without starting to suspect malice.] But, for the rest of us, here's a different summary. And note that, even though I'm a strong proponent of tmpfs, I say it might be better to skip it for wheezy -- so there's a chance this summary is not as biased. There are exactly two downsides: * In the everything on one partition scheme, there is less space available on swap that on /. • This is the big show-stopping problem. * A test case was shown where tmpfs is somewhat slower (by 15%), with reduced interactivity as well. • Needs some investigation; is not a typical case as you'd need large files on /tmp, nonlinear access patterns and high memory pressure at the same time. Still, it needs to be fixed somehow. And upsides: * Massive speed increase for I/O operations: • if syncs are involved: ~1x • if the file survives longer than 5-30 seconds: by disk's speed • if the disk is not touched at all¹: ~10x • if there's a writeout: depending on file/metadata ratio (no need for journaling/barriers) Note that these speed-ups touch I/O on /tmp only. Obviously, a process that's CPU-bound won't see noticeable gains, and others typically do quite a lot of things other than I/O. * No spin-ups of laptop drives. • There's always a spin-up even if the file has been deleted before that 5-30 seconds passes. Laptop mode reduces these somehow but you'd have to set dirty_expire_centisecs to some giant value to make them not have a practical effect, risking losing actual data. * Less wear of SSD drives. • Contrary to Serge's claims, SSDs are not an oddity, and it's not unlikely these will be a majority before wheezy becomes oldstable. I intentionally did not include cases not involving typical use, like NFSed or read-only / (we can assume a competent admin there), user errors (like comparing spaces you configured yourself), or merits of LVM with unallocated disk space (ie, a competent or semi-competent admin) vs dynamic swap files. This basically boils down to: efficiency vs failures for a newbie user. Folks in this thread tend to agree that it's the user who can't deal with partitions or the notion of separate space on separate filesystems who needs the most help, as the rest of us can configure the system. Still, it'd not a nice thing to need to do all those repetitive tweaks you may not even know about (like mounting everything noatime, again a good thing even compared to relatime). So, I'd say: * let's play it safe and not default to tmpfs for wheezy * do it properly later Current size defaults for /tmp are naive to the point of brokenness: with modern systems not being expected to ever use swap, we'd want to cap /tmp at 100% of swap rather than mere 20% -- but it's tricky to tell apart that from systems that actually do need swap for memory. And the same RAM/swap combination can need different settings based on what the system is supposed to do. But no matter how we tweak the ratio, it won't let some hapless user plop a 50GB file into /tmp because I have a lot of free space. This is not an insurmountable problem: /tmp might use some form of overlay that uses tmpfs for regular use and starts shunting to some area other than swap once it sees it is being used for large files. Or alternatively, there could possibly be a dynamic swap file on / earmarked for tmpfs pages only (not implemented yet?). Or... Too bad, any of these solutions would need a lot of testing, something for which there simply isn't time before wheezy. Let's go back here after the release. [¹]. During a short test; there'll be a spin-up later to write the directory even if the file has been deleted already. This is O(1) though. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. signature.asc Description: Digital signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote: Some people asked for a thread summary. So here it is. Sorry, but this is a biased summary, and therefore useless for what it intends to be. [...] /tmp on tmpfs is good quotes == No real quotes here. Most of this and other threads were about why /tmp on tmpfs is not that bad. But there're no real quotes explaining why it's good. This is wrong. There were several (including by me). You dismissed them, not considering them valid, but that doesn't mean they are. If you're going to post a thread summary, please do not filter out information you don't agree with. Otherwise you're not posting a thread summary, you're posting a 'my side of the fence' summary. Which is fine, but not the same thing. -- 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/20120610105120.gb9...@grep.be
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Adam Borowski wrote: Some people asked for a thread summary. So here it is. Seriously, can't you even read what's written to you? Yes, I know it was a biased summary. So as yours. But there's a difference between mine and yours. Mine is based on some real-world applications, yours is based on... what? Can you confirm your words with some real-world use cases, not on artificial tests? Sorry for being angry, but there's a limit to how many times you can have folks explain the basics of page cache without starting to suspect malice. Then stop explaining theories and show some examples. Theories can be wrong, examples are not. You missed some important part of the summary. I skipped almost everything, that was not related to /tmp or was not confirmed by some popular apps. The quotes I left were about *real* applications, mysql, gscan2pdf, dvd burning software, youtube, libreoffice, etc. And since there was no software in the upsides list I have nothing to quote. But, for the rest of us, here's a different summary. And note that, even though I'm a strong proponent of tmpfs, I say it might be better to skip it for wheezy -- so there's a chance this summary is not as biased. [...] And upsides: * Massive speed increase for I/O operations: Really? Well, I can also say that tmpfs is 1 times slower than ext3. But if I cannot confirm that on a real-world applications, my words mean nothing. So as yours. * No spin-ups of laptop drives. Have you ever checked that on real laptops? I did. The *only* case when /tmp caused additional spinup to me was a flash video. That's all. I remember no others. Since watching flash video was not the main purpose of that laptop it wasn't even 1% of total spinups. And it was completly solved with vm.laptop_mode=1. Do you want to know what have caused the rest of spinups? The main one was because of browser accessing the profile. That was about half of all the spinups. A major part was due to syslog writing to /var/log (by default it calls fsync on every line, I had to disable that). IIRC, another important part was because of wtmp being modified every time I open new console (I've put a hack to disable that too). One more part, not that large but still noticeable was because of /var/tmp/kdecache, so I reduced it as much as I could and put it to tmpfs (!). A small part of spinups were because of something being read from disk, so I hacked readahead so that it put more files in disk cache. That's all. /tmp was not even among top10. Why do you think that /tmp has anything to do with spinups in real world? * Less wear of SSD drives. Again, how many disk writes are related to /tmp? Have you ever checked that? Can you confirm your words with some numbers or at least some examples? Do you dismiss the theory (confirmed by Uoti Urpala test script) that tmpfs+swap INCREASE number of writes and are hence bad for SSD? • Contrary to Serge's claims, SSDs are not an oddity, and it's not unlikely these will be a majority before wheezy becomes oldstable. I never said that SSD is an oddity, I said, that putting /tmp on tmpfs gives you a feeling of false safety. That was based on my own experience. I `btrace`-d disk usage, I wrote scripts to identify applications doing most of the writes, and they were not related to /tmp. Your words look correct in theory, but they're not true in practice. That's why to avoid theoretical mistakes (any theory can be wrong) I tried to stick to some popular applications, because they're easy to check and they can't be wrong. This basically boils down to: efficiency vs failures for a newbie user. Yes. Theoretical efficiency vs practical failures. So, I'd say: * let's play it safe and not default to tmpfs for wheezy * do it properly later There're no real applications benefiting from /tmp on tmpfs now. Nothing will change later. There maybe fewer failures later, but still zero benefits to applications on the real world. Either now or later putting /tmp on tmpfs by default is useless in real world. That's the problem. :) -- 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/caoveneqacnt9wrfdocm-qtde2mnfgo0qzqrj-1_5bab8pzm...@mail.gmail.com
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge sergem...@gmail.com writes: 2012/6/10 Adam Borowski wrote: Some people asked for a thread summary. So here it is. Seriously, can't you even read what's written to you? Yes, I know it was a biased summary. I think you might start to piss off a few people now... Look at what you are quoting above. You introduced your biased summary like this: Some people asked for a thread summary. So here it is.. I will refrain from further comments. People can judge for themselves. 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/87txyjp85k@nemi.mork.no
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Wouter Verhelst wrote: Sorry, but this is a biased summary, and therefore useless for what it intends to be. Yes, I know. It's biased toward the /tmp and real-world applications. /tmp on tmpfs is good quotes No real quotes here. Most of this and other threads were about why /tmp on tmpfs is not that bad. But there're no real quotes explaining why it's good. This is wrong. There were several (including by me). You dismissed them, not considering them valid, but that doesn't mean they are. I dismissed everything that was not related to /tmp or some popular apps. A lot of people (including you) said that tmpfs makes things faster. But there were no examples of popular use-cases becoming faster because of /tmp on tmpfs, so I had nothing to quote. Nobody could provide examples or numbers of how much /tmp on tmpfs reduces amount of writes, and tests showed that tmpfs+swap may even increase amount of writes (hence not always good for SSD), tmpfs does not have 5% overflow safety, it does not help to protect from symlink attack and its name is not a reason to use it. :) (if I quoted it's called *tmp*fs for a reason in a tmpfs is good section it would be looking like humiliation, imho) If you need a tmpfs for your short builds you can mount it to /var/ram and use it there. But it's not related to /tmp, so I dismissed that too. Yes, tmpfs may be useful sometimes (and I even explained how to use it in Alternatives section), but that's outside of the topic of this thread if it's not about /tmp. If you'd said something like I put /tmp on tmpfs and my ethernet became twice faster, or Because of /tmp on tmpfs firefox loads pages 30% faster that would be a good thing to quote. Especially if you could provide some details so that anybody could check it. :) But there were no examples, just some theories. And I tried to avoid theories because they may be wrong (I explained why some popular theories are wrong in the Q/A section however). If you're going to post a thread summary, please do not filter out information you don't agree with. Otherwise you're not posting a thread summary, you're posting a 'my side of the fence' summary. I had to filter it. Otherwise it would be a copy of entire thread. :) Since the initial topic was not about tmpfs in general, but about /tmp and real-world applications, I filtered almost everything that's not related to it. It does not mean that I don't agree with that information. For example Stefan Lippers-Hollmann's test showed that kernel is building 15% faster on ext4 than on tmpfs, but I had not included that in summary, because people don't build their kernels in /tmp by default. I'm not stupidly opposite to tmpfs even for corner cases. I.e. if we could find that firefox works 30% faster with /tmp on tmpfs on PCs with 1GB RAM and disks with 1GB free space then... we could write an initscript, that checks for amount of RAM, free space and presence of firefox and mounts tmpfs to /tmp if it makes things faster. But there were no such examples, unfortunately. I could suggest a dozen of different solution, if only there were a problem to solve. Of course I could have missed some important examples about /tmp and real applications. Sorry if I did and I would be glad if you point them out. -- 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/caovenepbcx9pzr8nzttfm_x_p22pj9w0g0p4rhctkyv-tr5...@mail.gmail.com
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge wrote: 2012/6/10 Adam Borowski wrote: Some people asked for a thread summary. So here it is. Seriously, can't you even read what's written to you? Yes, I know it was a biased summary. So as yours. But there's a difference between mine and yours. Mine is based on some real-world applications, You've posted blatantly false claims. If you post claims like 1+1 equals 2 because the moon is made of cheese, then you're a moron, even if 1+1 does equal 2. And even if some of your arguments are valid, if you can't yourself tell the valid arguments apart from the crackpot claims that doesn't help your credibility. Do you dismiss the theory (confirmed by Uoti Urpala test script) that tmpfs+swap INCREASE number of writes and are hence bad for SSD? I think what the script shows is that there can be significant problems using tmpfs to hold large amounts of data, even if you have a lots of swap so that running out is not an issue. It doesn't show that the number of writes would increase on average. In general you seem to be quite clueless about the actual behavior of cache/swap, but you've still continued to make various claims about it. -- 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/1339341085.21597.72.camel@glyph.nonexistent.invalid
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote: * Less wear of SSD drives. • Contrary to Serge's claims, SSDs are not an oddity, and it's not unlikely these will be a majority before wheezy becomes oldstable. He didn’t say they were oddities. He said you should more worry about firmware bugs than worry about write cycles. And I think he is quite right. Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? If not, you think that getting /tmp away from disk will help much? Even if you consider rsyslog and logfiles, browser caches and so on? You have some interesting ideas, but I think they are only valuable for the common case if we can buy computers with better RAM to disk ratio. I checked some offers for new PCs (here in Germany). If you don’t buy an expensive gaming PC (with 16 or 12 GB RAM), you will get 4 GB (sometimes 6 or 8 GB). It’s even worse with notebooks. And let me guess: if you ask people if they want to buy a PC with 4 GB RAM and 2 TB disk or a PC with 8 GB RAM and 1 TB disk, they will choose the first one, because they know more about disk space than RAM. This basically boils down to: efficiency vs failures for a newbie user. Replace newbie user with default installation. Even experienced users may wish to choose default installation for common desktop systems. We have popularity-contest to get statistics about packages. Can this script be extended to get hardware information (e.g. RAM, disk space and partition layout)? So we would see what computer are used by our users and how it is configured. If most people only have 4 GB RAM, it is quite useless to waste it with a RAM disk. If most people already have separate tmp partitions, we don’t need it either. Current size defaults for /tmp are naive to the point of brokenness: with modern systems not being expected to ever use swap, we'd want to Well, if I start Virtual Box on my notebook (4 GB RAM), the system uses the swap partition. So it is not modern enough? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Uoti Urpala wrote: Yes, I know it was a biased summary. So as yours. But there's a difference between mine and yours. Mine is based on some real-world applications, You've posted blatantly false claims. If you post claims like 1+1 equals 2 because the moon is made of cheese, then you're a moron, even if 1+1 does equal 2. (I like this example :)) It could be, it's impossible to know everything in the world, I can be wrong. What false claim are you talking about? Do you dismiss the theory (confirmed by Uoti Urpala test script) that tmpfs+swap INCREASE number of writes and are hence bad for SSD? I think what the script shows is that there can be significant problems using tmpfs to hold large amounts of data, even if you have a lots of swap so that running out is not an issue. It doesn't show that the number of writes would increase on average. In general you seem to be quite clueless about the actual behavior of cache/swap, but you've still continued to make various claims about it. I was referencing your words: 2012/5/25 Uoti Urpala wrote: Thus, if you do multiple read iterations through a large set of data (which does not fit in memory) on tmpfs, each iteration does disk read AND write rather than just read. 2012/6/1 Uoti Urpala wrote: I haven't read the relevant kernel code, but that doesn't match the behavior I see. Reading a large file from tmpfs and then allocating memory results in large swap writes every time, even if the newly allocated memory is not itself immediately swapped out and the file should already be in swap from before. Reading from swap generates additional writes. It mean that tmpfs+swap may actually increase amount of writes instead of reducing it, isn't it? If you don't want me to reference your words, well, let's recheck that guess again. Pressing Enter on .tar.bz2 archive in mc will untar it to /tmp, burning a CD may generate iso-image in /tmp, let's check how many write there would be in case of tmpfs? Startup conditions: # free total used free sharedbuffers cached Mem: 1017588 850224 167364 0 63332 480588 -/+ buffers/cache: 306304 711284 Swap: 2249092 407642208328 That is 1GB RAM, 2GB swap, 300MB RAM in use (which is barely enough for almost empty gnome session), 700MB free. Swap is on /dev/sda3: # cat /proc/swaps FilenameTypeSizeUsed Priority /dev/sda3 partition 2249092 40764 -1 and is almost unused. Initial `iostat -k /dev/sda3` output: Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda3 9,7069,4680,04 122660 141340 So there were 140MB written yet. Now let's put a 1GB file on tmpfs: # dd if=/dev/zero of=/tmp/file bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 24,9147 s, 43,1 MB/s How many writes were done to swap? Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda3 12,2986,29 479,66 162996 906020 Hm, 750MB more... I have actually expected it to be about 300-400 MB, but well, I must have missed something like paging cluster... Anyway, it's still less than 1GB, so it looks like we saved 250MB of writes, right? Wrong! Because now we'll READ it back, that's what real app would do. # time cat /tmp/file /dev/null real1m58.916s user0m0.139s sys 0m17.287s So what do we have with r/w stats now: Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda3 60,86 567,86 885,1512436761938604 WOW! Reading that tmpfs-file we've done 1GB of reads AND 1GB WRITES. Instead of 1GB writes for real filesystem, we'd got 1.7GB for tmpfs+swap. Conclusion: using tmpfs+swap for files that increase amount of free RAM generate (at least 70%?) MORE WRITES than regular filesystem. And the more reads you do the more writes it generates. (Imho, that deserves a place in summary!) Does anybody still think that tmpfs+swap is good for SSD? ;) What part of my summary's wrong? The QA part? Those were just theories. Theories can be wrong, that's why I always ask for tests and examples, they can't be wrong. Theories are there just to explain results of the tests. Any theory is useful only when applied to a real life. When the theory does not match real life it replaced with another theory. That's how the entire physics work. :) Which of my theories is wrong, BTW? -- 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/caoveneowrbe0+061l7yop8zy8ehuxz_weggvwsbpavmo1l8...@mail.gmail.com
Re: Summary: Moving /tmp to tmpfs makes it useless
]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87d357ytuc@xoog.err.no
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? 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: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 06:13:24PM +0300, Serge wrote: 2012/6/10 Wouter Verhelst wrote: Sorry, but this is a biased summary, and therefore useless for what it intends to be. Yes, I know. It's biased toward the /tmp and real-world applications. /tmp on tmpfs is good quotes No real quotes here. Most of this and other threads were about why /tmp on tmpfs is not that bad. But there're no real quotes explaining why it's good. This is wrong. There were several (including by me). You dismissed them, not considering them valid, but that doesn't mean they are. I dismissed everything that was not related to /tmp or some popular apps. A lot of people (including you) said that tmpfs makes things faster. But there were no examples of popular use-cases becoming faster because of /tmp on tmpfs, so I had nothing to quote. You're not even trying. if tmpfs is faster than (say) ext4, then anything which uses /tmp will obviously speed up. Can I provide a use case where this will matter? Not necessarily. But then, can you provide a use case where this will *not* matter? Really? Nobody could provide examples or numbers of how much /tmp on tmpfs reduces amount of writes, and tests showed that tmpfs+swap may even increase amount of writes (hence not always good for SSD), True, but then swapping to an SSD is the best idea since 640kB is enough for everyone :-) tmpfs does not have 5% overflow safety, Because it doesn't need it. The 5% overflow safety exists for two reasons: - to avoid excessive fragmentation (which is not relevant for tmpfs) - to allow you to clean up when the filesystem does fill up. For tmpfs, you do that with: mount -o remount,size=foo /tmp where 'foo' is some size or percentage that's larger than what the tmpfs is currently mounted with. Now you clean up, and you reset to what it was before. If you're going to post a thread summary, please do not filter out information you don't agree with. Otherwise you're not posting a thread summary, you're posting a 'my side of the fence' summary. I had to filter it. Yes, but if you want to have any remote resemblance of objectivity, then what you do not do is filter out everything you don't agree with. -- 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/20120610175640.gb9...@grep.be
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote: On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote: Some people asked for a thread summary. So here it is. But, for the rest of us, here's a different summary. I've long thought that the wiki might be a good tool for trying to summarize the key points of a discussion. If there was hot disagreement about the points of relevance in the discussion, at least those disagreements would be moved off the mailing list and onto an edit war on a page on the wiki, which could be summarily ignored by other wiki users. The fact w.d.o is really slow atm would also help to cool down such interactions :) -- 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/20120610184542.GA16293@debian
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge wrote: 2012/6/10 Uoti Urpala wrote: You've posted blatantly false claims. If you post claims like 1+1 equals 2 because the moon is made of cheese, then you're a moron, even if 1+1 does equal 2. (I like this example :)) It could be, it's impossible to know everything in the world, I can be wrong. What false claim are you talking about? The problem is that you've posted quite a few of those false claims, and don't seem a have a clear distinction between things you actually know and things you only have a vague guess about. You seem to make claims about both equally. For example, the page you linked for your SSDs can take 50 years of writing before they wear out claim has a first paragraph saying durability IS again an issue - much more so than it was in 2007 when the original article with the 50 years claim was written (and even then that seems to have been some particularly durable high-end server hardware). As another example, this part from your FAQ is nonsense: When you read from ext3, the oldest part of the filecache is dropped and data is placed to RAM. But reading from swap means that your RAM is full, and in order to read a page from swap you must first write another page there. I.e. sequential read from ext3 turns into random write+read from swap. There is no such difference reading from a normal filesystem or reading from swap. Iterating reads from swap can trigger writes, but if that's what you're referring to here, you've clearly either failed to understand what actually happens or are writing a very misleading description. Do you dismiss the theory (confirmed by Uoti Urpala test script) that tmpfs+swap INCREASE number of writes and are hence bad for SSD? I think what the script shows is that there can be significant problems using tmpfs to hold large amounts of data, even if you have a lots of swap so that running out is not an issue. It doesn't show that the number of writes would increase on average. In general you seem to be quite clueless about the actual behavior of cache/swap, but you've still continued to make various claims about it. I was referencing your words: Yes, I did say that it can generate writes in some circumstances. However, that does not imply your tmpfs increases writes claim in general. In what has been a default installation, I think you'd normally start hitting the tmpfs size limit before the problematic behavior shown by the script would become a serious issue. It mainly shows that make the size limits bigger may not be a good solution to the space issue. -- 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/1339354920.21597.97.camel@glyph.nonexistent.invalid
Re: Summary: Moving /tmp to tmpfs makes it useless
]] Philipp Kern On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/873962zz6u@xoog.err.no
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 10:31:21PM +0200, Tollef Fog Heen wrote: Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. Ah, thank you for your explanations. But the documentation doesn’t sound encouraging. „man crypttab” gives a security warning and „man mount” says, this option is not sufficiently tested yet. 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: Summary: Moving /tmp to tmpfs makes it useless
Some people asked for a thread summary. So here it is. Seriously, can't you even read what's written to you? Yes, I know it was a biased summary. I think you might start to piss off a few people now... Look at what you are quoting above. You introduced your biased summary like this: Some people asked for a thread summary. So here it is.. I will refrain from further comments. People can judge for themselves. I think that it is really great that Serge wrote a summary. Serge, I thank you a lot. Your summary may not be prefect, but as it was suggested, there are tools like wiki.debian.org if there is some will to make a more structured document. Roger's email where he announced that the defaults were reverted was also very informative, as it provided a broader overview of why there are filesystems on tmpfs, and what is the role of /tmp in that context. In the absence of a final combined summary, I suggest to link to the ones of Roger, Serge and Adam in the next Developers News. http://wiki.debian.org/DeveloperNews#Using_RAM_for_temporary_files_.3F There are many long threads on -devel that are difficult to follow because of their large quantities of messages, to the point that I would almost call this a discrimination in the sense of our recent GR: I think it is pushing out contributions that we could have received if we self-moderated these posting bursts. For that reason, even if they are not perfect, I think that summaries are very welcome. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120610233432.gb7...@falafel.plessy.net
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Uoti Urpala wrote: What false claim are you talking about? The problem is that you've posted quite a few of those false claims [...] For example, the page you linked for your SSDs can take 50 years of writing before they wear out claim has a first paragraph saying durability IS again an issue Yes, it is an issue for MLC SSD disks, that's why in summary I wrote SLC SSD disks. I even explicitly wrote that it depends on chip type. That's why I gave that link, so people could check the type of SSD, get to know the SLC/MLC difference, read about the calculation method (which is valid for any SSD disk), and could decide whether they should worry. Everything looks correct. No false claims there... As another example, this part from your FAQ is nonsense: When you read from ext3, the oldest part of the filecache is dropped and data is placed to RAM. But reading from swap means that your RAM is full, and in order to read a page from swap you must first write another page there. I.e. sequential read from ext3 turns into random write+read from swap. There is no such difference reading from a normal filesystem or reading from swap. Iterating reads from swap can trigger writes, but if that's what you're referring to here, you've clearly either failed to understand what actually happens or are writing a very misleading description. Maybe I've just poorly expressed the theory. Basically it boils down to: In case of write large file then read it back (which is very common temporary file usage scenario) on the reading stage instead of plain sequential read (as it'd be for ext3) you'll get read+write from swap. Then I tried to explain: That's because on the write stage tmpfs was swapped out. The fact that it was swapped out means that the RAM is full, no free cache to use. And now when you start reading the file back, you need to read it from swap. But you cannot do that, because there's no free RAM. In order to read a page from swap you must first write another page of tmpfs there. That's why sequential read turns into random write+read from swap. That's what I wrote in the summary... or at least tried to write. When I was writing the summary it was just a theory, based on your email. I have not done any tests then. When a few hours ago I did it I was surprised how much true it was. It could be that my explanation is wrong, but test cannot be wrong: every read did generated equal number of writes. This actually means to me that as long as debian creates swap partition by default it should never create large tmpfs mountpoints by default, or it may badly affect SSD users. If you don't have a better explanation, then why do you think that mine was wrong? Of course if you do have a better explanation for results of that test I'm also interested to read it. I think you'd normally start hitting the tmpfs size limit before the problematic behavior shown by the script would become a serious issue. According to my theory the only thing you need to get the problem is a file on tmpfs that is larger than free RAM. I.e. if you have 1GB RAM and 600MB tmpfs (default for 2GB swap) you'll get swap reads+writes even with 500MB file, if your gnome+firefox took 600MB and you have less than 500MB RAM for cache. -- 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/caoveneo078mwd-qr1m8cnefejyauhtbquhmkdp3ckh-4har...@mail.gmail.com
