| |||||||||||||
Better than POSIX?Better than POSIX?Posted Mar 17, 2009 23:50 UTC (Tue) by drag (subscriber, #31333)In reply to: Better than POSIX? by vonbrand Parent article: Better than POSIX?
Who said it has to dissappeer when being re-opened? It got finished writing once and thus had a name. The fact that it was edited again doesn't change that. :)
It certainly will solve the write() then rename() issue. :)
And as I recalled I remember hearing about file system designers deliberately zero-ing out files for various reasons.
(Log in to post comments)
Postponing flush until close()? Posted Mar 18, 2009 23:17 UTC (Wed) by xoddam (subscriber, #2322) [Link]
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.
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.
|
|||||||||||||