Re: putting /tmp to memory help
On Sun, 30 Jan 2011, T o n g wrote: On Sat, 29 Jan 2011 23:01:09 -0500, Celejar wrote: I've given up on s2ram, the kernel method (echo mem /sys/power/state) works fine for me, at least with Kernel Mode Setting. I just tried that method. At first, it seemed to work wonderfully - system seemed to come back up, screen working, but then it went somewhat haywire . . . That's why there are so many wrapper tools that take care of such end cases. There are only 2 reasons why a bare-minimum kernel method work form someone, a) he is luckier than the guy wining the 649 ticket, or, b) ... or b) he uses embedded hardware which the kernel knows how to deal with fully. Actually, with KMS, my thinkpad (a T43/p) with a X300 radeon actually *needs* one to remove all hacks like acpi_sleep=s3_mode,s3_bios. Non-KMS X.org (as found in Lenny) needs it, while KMS X.org (as found in squeeze) will croak if you do that. -- 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-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110131161351.gc16...@khazad-dum.debian.net
Re: putting /tmp to memory help
On Tue, 25 Jan 2011 23:32:15 +0100 Sven Joachim svenj...@gmx.de wrote: On 2011-01-25 22:44 +0100, Celejar wrote: On Tue, 25 Jan 2011 22:02:50 +0100 Sven Joachim svenj...@gmx.de wrote: Yes, that's it (compare the output of free before and after hibernating to convince yourself). If you don't want to get your cache blown away, use suspend (to RAM) rather than hibernation. I'd love to (sometimes), but I've never been able to get it to work on this machine, even after a fair bit of futzing with s2ram options. I've given up on s2ram, the kernel method (echo mem /sys/power/state) works fine for me, at least with Kernel Mode Setting. I just tried that method. At first, it seemed to work wonderfully - system seemed to come back up, screen working, but then it went somewhat haywire - keyboard and mouse (touchpad) seemed to work, and I could switch windows via Alt-Tab, but no window / application (including my terminal emulator) would accept any keyboard input - the window would just stop responding and stop refreshing. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110129230109.30321bd2.cele...@gmail.com
Re: putting /tmp to memory help
Celejar: I'm somewhat confused about this. My system has 2GB of RAM, and I have: $ uptime 20:46:09 up 5 days, 5:30, 9 users, load average: 0.06, 0.09, 0.25 $ free total used free sharedbuffers cached Mem: 206517210473121017860 0 66064 357512 -/+ buffers/cache: 6237361441436 Swap: 1949688 1023641847324 This shows that ~620MB are used for applications and data. About 400MB is used for buffers/cache (don't ask me what the difference is). $ df | grep tmp tmpfs 103258416 1032568 1% /lib/init/rw tmpfs 1032584 0 1032584 0% /dev/shm none 1032584 2440 1030144 1% /tmp So my /tmp is using 1GB. No. Your /tmp might grow up to 1GB, but it only occupies what's really necessary. This is the main difference between tmpfs and a traditional RAM disk. Someone posted an interesting link about this topic, IIRC in this very thread. J. -- I use a Playstation to block out the existence of my partner. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: putting /tmp to memory help
On Tue, 25 Jan 2011 08:49:57 +0100 Sven Joachim svenj...@gmx.de wrote: On 2011-01-25 02:50 +0100, Celejar wrote: On Mon, 24 Jan 2011 17:41:07 -0600 Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: ... tmpfs doesn't reserve much (if any) memory. So, unless it is being actively used by files in the tmpfs, it can be used by other applications. I'm somewhat confused about this. My system has 2GB of RAM, and I have: $ uptime 20:46:09 up 5 days, 5:30, 9 users, load average: 0.06, 0.09, 0.25 $ free total used free sharedbuffers cached Mem: 206517210473121017860 0 66064 357512 -/+ buffers/cache: 6237361441436 Swap: 1949688 1023641847324 $ df | grep tmp tmpfs 103258416 1032568 1% /lib/init/rw tmpfs 1032584 0 1032584 0% /dev/shm none 1032584 2440 1030144 1% /tmp So my /tmp is using 1GB. No, because more than 99% of the space on /tmp are free. But if that memory isn't actually reserved for the tmpfs filesystem, and is actually available for other uses (until /tmp fills up), than shouldn't that memory either be reported as 'free' by free, or used for disk caching, etc., and therefore be reported as 'used'? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125150327.57f185cc.cele...@gmail.com
Re: putting /tmp to memory help
On Tue, 25 Jan 2011 09:42:24 +0100 Jochen Schulz m...@well-adjusted.de wrote: Celejar: I'm somewhat confused about this. My system has 2GB of RAM, and I have: $ uptime 20:46:09 up 5 days, 5:30, 9 users, load average: 0.06, 0.09, 0.25 $ free total used free sharedbuffers cached Mem: 206517210473121017860 0 66064 357512 -/+ buffers/cache: 6237361441436 Swap: 1949688 1023641847324 This shows that ~620MB are used for applications and data. About 400MB is used for buffers/cache (don't ask me what the difference is). $ df | grep tmp tmpfs 103258416 1032568 1% /lib/init/rw tmpfs 1032584 0 1032584 0% /dev/shm none 1032584 2440 1030144 1% /tmp So my /tmp is using 1GB. No. Your /tmp might grow up to 1GB, but it only occupies what's really necessary. This is the main difference between tmpfs and a traditional RAM disk. Someone posted an interesting link about this topic, IIRC in this very thread. But IIUC, on a linux system that's been up for a while, with moderate usage, pretty much all available memory should be 'used', as it will be used for disk cache if not needed by applications. So if the tmpfs isn't reserving the full 1GB, shouldn't that memory be 'used' in the output of 'free'? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125151606.90890d78.cele...@gmail.com
Re: putting /tmp to memory help
On 2011-01-25 21:03 +0100, Celejar wrote: On Tue, 25 Jan 2011 08:49:57 +0100 Sven Joachim svenj...@gmx.de wrote: On 2011-01-25 02:50 +0100, Celejar wrote: On Mon, 24 Jan 2011 17:41:07 -0600 Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: ... tmpfs doesn't reserve much (if any) memory. So, unless it is being actively used by files in the tmpfs, it can be used by other applications. I'm somewhat confused about this. My system has 2GB of RAM, and I have: $ uptime 20:46:09 up 5 days, 5:30, 9 users, load average: 0.06, 0.09, 0.25 $ free total used free sharedbuffers cached Mem: 206517210473121017860 0 66064 357512 -/+ buffers/cache: 6237361441436 Swap: 1949688 1023641847324 $ df | grep tmp tmpfs 103258416 1032568 1% /lib/init/rw tmpfs 1032584 0 1032584 0% /dev/shm none 1032584 2440 1030144 1% /tmp So my /tmp is using 1GB. No, because more than 99% of the space on /tmp are free. But if that memory isn't actually reserved for the tmpfs filesystem, and is actually available for other uses (until /tmp fills up), than shouldn't that memory either be reported as 'free' by free, or used for disk caching, etc., and therefore be reported as 'used'? I'm not sure I can parse this correctly. If you're referring to half of your memory being free, that's certainly a bit unusual, but it probably can be explained. Maybe you hibernated your system in the five days it's been up, or you were watching a DVD and ejected the media. Or you have just terminated a process that used a lot of RAM. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj28hgbm@turtle.gmx.de
Re: putting /tmp to memory help
On Tue, 25 Jan 2011 21:35:41 +0100 Sven Joachim svenj...@gmx.de wrote: On 2011-01-25 21:03 +0100, Celejar wrote: On Tue, 25 Jan 2011 08:49:57 +0100 Sven Joachim svenj...@gmx.de wrote: On 2011-01-25 02:50 +0100, Celejar wrote: On Mon, 24 Jan 2011 17:41:07 -0600 Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: ... tmpfs doesn't reserve much (if any) memory. So, unless it is being actively used by files in the tmpfs, it can be used by other applications. I'm somewhat confused about this. My system has 2GB of RAM, and I have: $ uptime 20:46:09 up 5 days, 5:30, 9 users, load average: 0.06, 0.09, 0.25 $ free total used free sharedbuffers cached Mem: 206517210473121017860 0 66064 357512 -/+ buffers/cache: 6237361441436 Swap: 1949688 1023641847324 $ df | grep tmp tmpfs 103258416 1032568 1% /lib/init/rw tmpfs 1032584 0 1032584 0% /dev/shm none 1032584 2440 1030144 1% /tmp So my /tmp is using 1GB. No, because more than 99% of the space on /tmp are free. But if that memory isn't actually reserved for the tmpfs filesystem, and is actually available for other uses (until /tmp fills up), than shouldn't that memory either be reported as 'free' by free, or used for disk caching, etc., and therefore be reported as 'used'? I'm not sure I can parse this correctly. If you're referring to half of your memory being free, that's certainly a bit unusual, but it probably Yes. can be explained. Maybe you hibernated your system in the five days it's been up, or you were watching a DVD and ejected the media. Or you have just terminated a process that used a lot of RAM. You're right; I see now that 'free' reports only 317376 free. This is a laptop, and I do hibernate it a couple of times a day, so I suppose that the cache(s) are thrown away to use the RAM for hibernation (and to avoid pointlessly saving cached disk data in RAM back to disk), and then when the system is restored, the RAM becomes free again until it's once again used for cache or application storage? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125154826.481af9a7.cele...@gmail.com
Re: putting /tmp to memory help
On 2011-01-25 21:48 +0100, Celejar wrote: You're right; I see now that 'free' reports only 317376 free. This is a laptop, and I do hibernate it a couple of times a day, so I suppose that the cache(s) are thrown away to use the RAM for hibernation (and to avoid pointlessly saving cached disk data in RAM back to disk), and then when the system is restored, the RAM becomes free again until it's once again used for cache or application storage? Yes, that's it (compare the output of free before and after hibernating to convince yourself). If you don't want to get your cache blown away, use suspend (to RAM) rather than hibernation. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei80hf2d@turtle.gmx.de
Re: putting /tmp to memory help
On Tue, 25 Jan 2011 22:02:50 +0100 Sven Joachim svenj...@gmx.de wrote: On 2011-01-25 21:48 +0100, Celejar wrote: You're right; I see now that 'free' reports only 317376 free. This is a laptop, and I do hibernate it a couple of times a day, so I suppose that the cache(s) are thrown away to use the RAM for hibernation (and to avoid pointlessly saving cached disk data in RAM back to disk), and then when the system is restored, the RAM becomes free again until it's once again used for cache or application storage? Yes, that's it (compare the output of free before and after hibernating to convince yourself). If you don't want to get your cache blown away, use suspend (to RAM) rather than hibernation. I'd love to (sometimes), but I've never been able to get it to work on this machine, even after a fair bit of futzing with s2ram options. [FTR, it's an Acer Aspire 3690.] Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125164415.7cf07189.cele...@gmail.com
Re: putting /tmp to memory help
On 2011-01-25 22:44 +0100, Celejar wrote: On Tue, 25 Jan 2011 22:02:50 +0100 Sven Joachim svenj...@gmx.de wrote: Yes, that's it (compare the output of free before and after hibernating to convince yourself). If you don't want to get your cache blown away, use suspend (to RAM) rather than hibernation. I'd love to (sometimes), but I've never been able to get it to work on this machine, even after a fair bit of futzing with s2ram options. I've given up on s2ram, the kernel method (echo mem /sys/power/state) works fine for me, at least with Kernel Mode Setting. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vy8haxc@turtle.gmx.de
Re: putting /tmp to memory help
On Sun, 2011-01-23 at 05:47 -0800, kellyremo wrote: to memory means: mounting a ~2 GByte filesystem [ tmpfs?, or ramfs? ], and put the /tmp on it. [ e.g.: 4 GByte ram in the pc ]. what to write in the /etc/fstab? I would like to collect the [ answers too:P ]: Advantages: - Memory is way faster then HDD/SSD, so it could speed things up - SSD amortization is less Disadvantages: - Security? [ how to set this up to be secure? any clear howtos/links regarding it? :O ] Really thank you for any good help... Another advantage you have is that it is on a separate partition and one can thus remove many of the attack vectors used to run malicious software. For example, we run ours with: none/tmptmpfs size=128m,mode=1777,noexec,nosuid,nodev 0 0 The noexec,nosuid,nodev apparently does a good job of stopping malware from running in /tmp. However, it also keeps legitimate execution from happening in /tmp. For example, before we install or update packages, we need to remount it exec,suid,dev (probably just the first two are necessary) in order for the package configuration scripts to run - John -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295862684.8976.11.ca...@denise.theartistscloset.com
Re: putting /tmp to memory help
Isn't messing with volatile /tmp somewhat a moot point, given that the Linux memory manager manages virtual memory anyway? I mean, if /tmp is heavily used by your system, it will be cached in memory anyway. With 4 GB of RAM (as mentioned by kellyremo), you'll end with probably your entire payload (and not just your /tmp) running from RAM. So what's to be gained with a /tmp in RAM, really? In addition, there is a possibility that dedicating 2 GB of RAM to /tmp, you could end up forcing your system to start swapping out. Which would instantly defeat any speed improvement(s) you might have gained. Linux memory management is quite competent all-round IMHO, and it would take an extremely specific/border/particular user case to warrant moving /tmp to a RAM disk. Any opinions? -- Cheerio, Klistvud --- I've thought about this on the premise that if I put the 16GB of RAM my month board can support in than I would have plenty of system memory to run the entire OS from RAM, even while using VM's But I only know about such things from theory... TeddyB
Re: putting /tmp to memory help
In 821513319-1295910389-cardhu_decombobulator_blackberry.rim.net-57593962- @bda029.bisx.prod.on.blackberry, teddi...@tmo.blackberry.net wrote: Isn't messing with volatile /tmp somewhat a moot point, given that the Linux memory manager manages virtual memory anyway? I mean, if /tmp is heavily used by your system, it will be cached in memory anyway. With 4 GB of RAM (as mentioned by kellyremo), you'll end with probably your entire payload (and not just your /tmp) running from RAM. So what's to be gained with a /tmp in RAM, really? Not waiting on writes to disk. Also freeing up disk I/O bandwidth for other uses. fsync() or fdatasync() on tmpfs is virtually a no-op. fsync() or fdatasync() on a fully-cachec ext2/3/4 filesystem can still take quite a while. In addition, there is a possibility that dedicating 2 GB of RAM to /tmp, you could end up forcing your system to start swapping out. tmpfs doesn't reserve much (if any) memory. So, unless it is being actively used by files in the tmpfs, it can be used by other applications. it would take an extremely specific/border/particular user case to warrant moving /tmp to a RAM disk. If the points you mentioned were salient at all, that might be the case. In practice, putting /tmp on a tmpfs almost always speeds up both desktops and servers. It can make sense not to use the default of 1/2 of RAM for /tmp, but since it isn't a hard reservation it doesn't matter much. I've been running on a 2GB tmpfs /tmp for years. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: putting /tmp to memory help
On Mon, 24 Jan 2011 17:41:07 -0600 Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: ... tmpfs doesn't reserve much (if any) memory. So, unless it is being actively used by files in the tmpfs, it can be used by other applications. I'm somewhat confused about this. My system has 2GB of RAM, and I have: $ uptime 20:46:09 up 5 days, 5:30, 9 users, load average: 0.06, 0.09, 0.25 $ free total used free sharedbuffers cached Mem: 206517210473121017860 0 66064 357512 -/+ buffers/cache: 6237361441436 Swap: 1949688 1023641847324 $ df | grep tmp tmpfs 103258416 1032568 1% /lib/init/rw tmpfs 1032584 0 1032584 0% /dev/shm none 1032584 2440 1030144 1% /tmp So my /tmp is using 1GB. What is my 'free' saying? Why is so much memory free? IIUC, the 'free' column in the first line should generally be close to zero if all the memory is available and not reserved, and I'm pretty sure that with the tmpfs enabled, it never drops below about a GB or so. The second line, OTOH, does seem to show that only ~620MB are actually in use, and the rest in free. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124205021.4f32e0d1.cele...@gmail.com
Re: putting /tmp to memory help
On 2011-01-25 02:50 +0100, Celejar wrote: On Mon, 24 Jan 2011 17:41:07 -0600 Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: ... tmpfs doesn't reserve much (if any) memory. So, unless it is being actively used by files in the tmpfs, it can be used by other applications. I'm somewhat confused about this. My system has 2GB of RAM, and I have: $ uptime 20:46:09 up 5 days, 5:30, 9 users, load average: 0.06, 0.09, 0.25 $ free total used free sharedbuffers cached Mem: 206517210473121017860 0 66064 357512 -/+ buffers/cache: 6237361441436 Swap: 1949688 1023641847324 $ df | grep tmp tmpfs 103258416 1032568 1% /lib/init/rw tmpfs 1032584 0 1032584 0% /dev/shm none 1032584 2440 1030144 1% /tmp So my /tmp is using 1GB. No, because more than 99% of the space on /tmp are free. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwshifru@turtle.gmx.de
putting /tmp to memory help
to memory means: mounting a ~2 GByte filesystem [ tmpfs?, or ramfs? ], and put the /tmp on it. [ e.g.: 4 GByte ram in the pc ]. what to write in the /etc/fstab? I would like to collect the [ answers too:P ]: Advantages: - Memory is way faster then HDD/SSD, so it could speed things up - SSD amortization is less Disadvantages: - Security? [ how to set this up to be secure? any clear howtos/links regarding it? :O ] Really thank you for any good help...
Re: putting /tmp to memory help
hey, i am also intertested... :) On 2011.01.23. 14:47, kellyremo wrote: to memory means: mounting a ~2 GByte filesystem [ tmpfs?, or ramfs? ], and put the /tmp on it. [ e.g.: 4 GByte ram in the pc ]. what to write in the /etc/fstab? I would like to collect the [ answers too:P ]: Advantages: - Memory is way faster then HDD/SSD, so it could speed things up - SSD amortization is less Disadvantages: - Security? [ how to set this up to be secure? any clear howtos/links regarding it? :O ] Really thank you for any good help... \
Re: putting /tmp to memory help
On Sun, 23 Jan 2011, kellyremo wrote: to memory means: mounting a ~2 GByte filesystem [ tmpfs?, or ramfs? ], and put the /tmp on it. [ e.g.: 4 GByte ram in the pc ]. what to write in the /etc/fstab? tmpfs /tmptmpfs defaults,nosuid,nodev,mode=1777,size=1G In squeeze, edit /etc/default/tmpfs: SHM_SIZE=6G TMPFS_SIZE=1G RUN_SIZE=10M LOCK_SIZE=1M RW_SIZE=10M (adjust to your needs). Disadvantages: - Security? [ how to set this up to be secure? any clear howtos/links regarding it? :O ] tmpfs does not support security labels in 2.6.32, which limits SELINUX heavily. There is no workaround (unless Debian backported the support to 2.6.32, I didn't check). Switch to per-user TMP directories is recommended. -- 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-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110123140827.ge24...@khazad-dum.debian.net
Re: putting /tmp to memory help
Dne, 23. 01. 2011 15:08:27 je Henrique de Moraes Holschuh napisal(a): On Sun, 23 Jan 2011, kellyremo wrote: to memory means: mounting a ~2 GByte filesystem [ tmpfs?, or ramfs? ], and put the /tmp on it. [ e.g.: 4 GByte ram in the pc ]. what to write in the /etc/fstab? tmpfs /tmptmpfs defaults,nosuid,nodev,mode=1777,size=1G In squeeze, edit /etc/default/tmpfs: SHM_SIZE=6G TMPFS_SIZE=1G RUN_SIZE=10M LOCK_SIZE=1M RW_SIZE=10M (adjust to your needs). Disadvantages: - Security? [ how to set this up to be secure? any clear howtos/links regarding it? :O ] tmpfs does not support security labels in 2.6.32, which limits SELINUX heavily. There is no workaround (unless Debian backported the support to 2.6.32, I didn't check). Switch to per-user TMP directories is recommended. -- 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 Isn't messing with volatile /tmp somewhat a moot point, given that the Linux memory manager manages virtual memory anyway? I mean, if /tmp is heavily used by your system, it will be cached in memory anyway. With 4 GB of RAM (as mentioned by kellyremo), you'll end with probably your entire payload (and not just your /tmp) running from RAM. So what's to be gained with a /tmp in RAM, really? In addition, there is a possibility that dedicating 2 GB of RAM to /tmp, you could end up forcing your system to start swapping out. Which would instantly defeat any speed improvement(s) you might have gained. Linux memory management is quite competent all-round IMHO, and it would take an extremely specific/border/particular user case to warrant moving /tmp to a RAM disk. Any opinions? -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295793980.5499.0@compax
Re: putting /tmp to memory help
On Du, 23 ian 11, 15:46:20, Klistvud wrote: Any opinions? No, just facts ;) $ free total used free sharedbuffers cached Mem: 20596521847748 211904 0 153008 885512 -/+ buffers/cache: 8092281250424 Swap: 975204 0 975204 $ df -hT FilesystemTypeSize Used Avail Use% Mounted on /dev/sda6 ext39.2G 4.8G 4.0G 55% / tmpfstmpfs 1006M 0 1006M 0% /lib/init/rw udev tmpfs 1004M 228K 1004M 1% /dev tmpfstmpfs 1006M 0 1006M 0% /dev/shm /dev/sda2 ext3 19G 6.5G 11G 38% /home /dev/sda8 xfs104G 102G 2.4G 98% /home/amp/big /dev/sda7 ext39.2G 4.5G 4.3G 52% /var tmpfstmpfs 1006M 364K 1006M 1% /tmp $ uptime 18:07:19 up 1 day, 19:56, 10 users, load average: 0.57, 0.77, 0.67 $ ps aux | grep wc -l 198 And to answer OP's question: Boot from a live CD or so, and then: # mv /tmp /oldtmp # mkdir /tmp echo tmpfs tmp tmpfs /etc/fstab If you're satisfied with the results you can # rm /oldtmp -rf 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: putting /tmp to memory help
Hello, Klistvud a écrit : Isn't messing with volatile /tmp somewhat a moot point, given that the Linux memory manager manages virtual memory anyway? I mean, if /tmp is heavily used by your system, it will be cached in memory anyway. With 4 GB of RAM (as mentioned by kellyremo), you'll end with probably your entire payload (and not just your /tmp) running from RAM. So what's to be gained with a /tmp in RAM, really? Save some useless write operations to the disk ? That could be useful is the disk is busy. In addition, there is a possibility that dedicating 2 GB of RAM to /tmp, you could end up forcing your system to start swapping out. Which would instantly defeat any speed improvement(s) you might have gained. Linux memory management is quite competent all-round IMHO, Tmpfs can be swapped out too, and if, according to you, Linux memory management is quite competent, why not let it decide what is most worth writing to disk or keeping in RAM ? and it would take an extremely specific/border/particular user case to warrant moving /tmp to a RAM disk. Tmpfs is not a RAM disk (RAM-based block device), it is a filesystem in virtual memory. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3c551d.3090...@plouf.fr.eu.org
Re: putting /tmp to memory help
Dne, 23. 01. 2011 17:19:41 je Pascal Hambourg napisal(a): Tmpfs is not a RAM disk (RAM-based block device), it is a filesystem in virtual memory. Didn't know that. Damn clever. I stand corrected. -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295811576.5499.2@compax
Re: putting /tmp to memory help
Dne, 23. 01. 2011 17:19:41 je Pascal Hambourg napisal(a): P Tmpfs is not a RAM disk (RAM-based block device), it is a filesystem in P virtual memory. On Sun, 23 Jan 2011 20:39:36 +0100, Klistvud quotati...@aliceadsl.fr said: K Didn't know that. Damn clever. I stand corrected. http://landley.net/writing/rootfs-intro.html has a nice, short description of ramdisk vs. ramfs. -- Karl Vogel I don't speak for the USAF or my company The San Francisco Cable cars are the only mobile National Monuments. --odd but true -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124004048.02cc7b...@kev.msw.wpafb.af.mil
Re: putting /tmp to memory help
On Sun, 2011-01-23 at 05:47 -0800, kellyremo wrote: to memory means: mounting a ~2 GByte filesystem [ tmpfs?, or ramfs? ], and put the /tmp on it. [ e.g.: 4 GByte ram in the pc ]. what to write in the /etc/fstab? I would like to collect the [ answers too:P ]: Advantages: - Memory is way faster then HDD/SSD, so it could speed things up - SSD amortization is less Disadvantages: - Security? [ how to set this up to be secure? any clear howtos/links regarding it? :O ] Really thank you for any good help... How many mailing lists are you sending this to? It does not help anyone (yourself included) to bcc cross post such a generic email to 3+ mailing lists. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295837956.25748.20.ca...@azkaban.toh
