On Fri, 25 Nov 2011 18:57:22 +0100 Tom Gundersen <teg@xxxxxxx> wrote: > On Fri, Nov 25, 2011 at 6:31 PM, Leonid Isaev <lisaev@xxxxxxxxxxxx> wrote: > > On Fri, 25 Nov 2011 18:07:18 +0100 > > Geert Hendrickx <geert@xxxxxxxxxxxx> wrote: > > > >> On Fri, Nov 25, 2011 at 10:55:55 -0600, Leonid Isaev wrote: > >> > Actually, what is stupid is keeping /tmp in RAM. It is an important dir, > >> > where you might have an valuable info in case of a system crash. I could > >> > never understand the logic behind this choice. > >> > >> > >> Reducing disk i/o. > >> > >> > >> Geert > >> > >> > > > > I find this a very weak excuse, because the normal desktop operation is not > > I/O bound, and the dafaults must be safest. If you compile a lot/use a > > lot of DB stuff, just mount /tmp to RAM in fstab but this is a special case. > > Note that: > > 1) FHS says: "Programs must not assume that any files or directories > in /tmp are preserved between invocations of the program." I didn't say anything about programs -- I meant the administrator. Suppose you came across a pdf file which freezes your evince and the whole X. Then you'll definitely would like to have a closer look at it and send it do evince devs, but it's gone because of hard reboot. > > 2) the contents of /tmp is deleted by initscripts on boot, so if you > want to access stuff in /tmp after an unclean shutdown you somehow > have to circumvent that. Exactly -- use livecd, otherwise why not clean it rc.shutdown, on unmount? > > Given the above, there is no reason not to use tmpfs on /tmp (and > plenty of reasons to do so). If extra space is required on /tmp, then > the most efficient solution is to add to the available swap space. > > If you have important data, don't put it in /tmp or /var/tmp as > neither has any guarantees about persistence. > > -t -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Attachment:
signature.asc
Description: PGP signature
