| |||||||||||||
POSIX v. reality: A position on O_PONIESPOSIX v. reality: A position on O_PONIESPosted Sep 9, 2009 20:33 UTC (Wed) by kjp (subscriber, #39639)Parent article: POSIX v. reality: A position on O_PONIES
Also, in reply to "no one ever, ever wrote "creat(); write(); close(); rename();" and hoped they would get an empty file if the system crashed during the next 5 minutes. "
I have an example of when this actually can be useful (however to be clear, I am very much in favor of rename being safe by default).
A web interface needs to display a text dump from a daemon to a user. The daemon writes out /tmp/daemon-dump.tmp, and renames it to /tmp/daemon-dump.txt. It does this since concurrent users in the web site may still be accessing the previous version. However, on a crash it doesn't matter what happens to this file since it is always refreshed by a web process before starting display.
In a nutshell, the rename here is for IPC concurrency only and not related to any crash consistency. However, it is FAR more sane to add a fcntl flag to say (O_EAT_MY_DATA_SPEED_TOO_IMPORTANT) for these speed freaks than brick files or entire computers....
(Log in to post comments)
POSIX v. reality: A position on O_PONIES Posted Sep 9, 2009 21:00 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] 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.
POSIX v. reality: A position on O_PONIES Posted Sep 9, 2009 21:03 UTC (Wed) by sbergman27 (guest, #10767) [Link]
> 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 doing so is far more likely to cause problems than to help solve them.
POSIX v. reality: A position on O_PONIES Posted Sep 9, 2009 22:20 UTC (Wed) by iabervon (subscriber, #722) [Link]
Actually, systems that want that probably really want to mount tmpfs on /tmp. After a system crash, they could be sure that the directory accounts for all of the changes and the exact order of operations, including the contents being wiped out after all of those operations. In your example, there's no need to write the file to disk at all, except to free up RAM.
POSIX v. reality: A position on O_PONIES Posted Sep 10, 2009 8:58 UTC (Thu) by lysse (guest, #3190) [Link]
> O_EAT_MY_DATA_SPEED_TOO_IMPORTANT
... O_PONYCRAP ?
POSIX v. reality: A position on O_PONIES Posted Sep 17, 2009 16:04 UTC (Thu) by forthy (guest, #1525) [Link] O_RACE_HORSE | O_ON_STEROIDS That's obvious, isn't it?
|
|||||||||||||