On Friday 25 November 2005 23:31, Rob Landley wrote: > On Friday 25 November 2005 15:04, Nix wrote: > > The ~/.kde directory doesn't contain temporary files, but persistent > > state: > > ~/.kde/share/apps/kmail/lock is persistent state? > > I do know that half the time the darn battery runs out and kde suddely > shuts down my desktop without the courtesy of even _warning_ me first (oh > it pops up a window three seconds before doing it), kmail doesn't have a > chance to zap this file before being killed and thus I have to drill down > and zap the sucker by hand or it'll refuse to run when I boot back up. > > Circa Red Hat 9, konqueror's cache files were under .kde. I have no idea > what the junk in .kde/share/apps/kpdf is for... > > But I take your point. They've instituted a policy and tried to clean this > up. Similarly, .bash_history, .bittorrent, .DCOPserver*, .mcop, and all > the other fun stuff written into home must be considered persistent state. > > > and the same is true of /var/spool, > > Doesn't /var/spool/cups contains files spooled to the printer? (I dunno, > the only printer in the house is hooked up to my fiance's windows machine.)
Spool *is* persistent... this is why cups is a daemon. Indeed, when you power on a printer and it starts printing without further action, you (or the average user, or me for a couple of seconds) say "it's a daemon's fault!"... > > > things like vi would create temporary files in /tmp, > > > > /var/tmp, because the entire point of those files was to survive a > > reboot. > > Is it? I thought it was to support undo. > Files that live for brief instants never get written out to disk anyway. > That's why there's the delay before dirty pages in the page cache are > scheduled for writeout. So tmpfs doesn't help there. That's not entirely correct for performances - the file could not get written out, but on most filesystems (excluding XFS, Reiser4 and some experimental ext3 version) a few preparatory steps (block allocation, for instance, and that involves poking through free list bitmaps and is even computationally intensive*) are done. Delayed allocation was invented exactly for that. * on a RAID array with ext3, in a benchmark, it limited writeout speed downto 300 Mb/s instead of 500 Mb/s (See OLS 2005, ext3 paper). > > - users. A *lot* of my users dump temporary crud in /tmp: > *shrug*. The truly transient stuff never leaves the page cache, no matter > what the filesystem. (Especially if you mount with noatime, which is the > norm these days.) I've seen it rarely used... only Gentoo suggests that. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
