Not logged in
Log in now
Create an account
Subscribe to LWN
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
LWN.net Weekly Edition for June 6, 2013
In the actual physical file system image committed to disk; Don't name partially written files.
That would pretty much get what everybody wants. I suppose it's much much complicated then that, of course. I'll take "good enough" any day.
Better than POSIX?
Posted Mar 17, 2009 17:52 UTC (Tue) by vonbrand (subscriber, #4458)
"Don't name partially written files" would mean that nothing has a name until the file is closed, and the file has to disappear whenever it is opened for writing... I'd take the current mess situation any time in the face of that.
Posted Mar 17, 2009 23:50 UTC (Tue) by drag (subscriber, #31333)
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.
Postponing flush until close()?
Posted Mar 18, 2009 23:17 UTC (Wed) by xoddam (subscriber, #2322)
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.
Posted Mar 19, 2009 23:34 UTC (Thu) by xoddam (subscriber, #2322)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds