POSIX v. reality: A position on O_PONIES

POSIX v. reality: A position on O_PONIES

Posted Sep 9, 2009 21:00 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)
In reply to: POSIX v. reality: A position on O_PONIES by kjp
Parent article: POSIX v. reality: A position on O_PONIES

I posit that there should rarely be a good reason to run fsck on /tmp. Keeping the contents of /tmp across a crash may be useful for forensics (ie. "why did we crash?") and maybe rescuing a couple things, but otherwise you should be able to jettison it if there are any issues with the filesystem holding it, so long as /tmp is in its own filesystem. (That said, my RHEL4 box has a /tmp/lost+found. Hmmm.)

I'd further posit that nobody hopes for the empty file across a system crash. (If they did, they'd unlink() it just after opening it and before writing to it so that the file effectively evaporates on a crash. Ok, it might show up in lost+found, but only root can play there.) In your example, the programmer simply doesn't care. The programmer hopes for peak performance and doesn't really care if that means the file has garbage if the system crashes. If the contents were perfectly preserved without slowing the program down, I doubt the programmer in your example would care.

---

(Log in to post comments)