| |||||||||||||
Postponing flush until close()?Postponing flush until close()?Posted Mar 18, 2009 23:17 UTC (Wed) by xoddam (subscriber, #2322)In reply to: Better than POSIX? by drag Parent article: Better than POSIX?
Am I to understand that you're proposing that any changes to a file (metadata and data blocks alike) not be flushed to disk until close()?
That doesn't really sound like a good way to enhance recoverability. For applications that keep large files (eg. caches) open for a long time and update them piecemeal, it sounds like sheer madness.
Applications that truncate existing data before rewriting it are asking for trouble, though I appreciate a filesystem that doesn't exacerbate the race condition by promptly truncating the inode but delaying the flush of the new data blocks for several seconds. Ted has already fixed that particular issue heuristically by delaying truncation until it is time to flush the data. Flushing *early* on close() couldn't hurt integrity but could hurt performance quite a bit.
(Log in to post comments)
Postponing flush until close()? Posted Mar 19, 2009 23:34 UTC (Thu) by xoddam (subscriber, #2322) [Link]
Sorry, I just read the patch. If a file has been opened with O_TRUNC then it will indeed be flushed (early) when closed. The race condition still exists of course, but flushing on close will keep the risky interval relatively short in the vast majority of cases.
|
|||||||||||||