Messages in this thread | | | Date | Fri, 27 Mar 2009 21:11:13 +0100 | From | "Andreas T.Auer" <> | Subject | Re: Linux 2.6.29 |
| |
On 2009-03-27 20:32 Theodore Tso wrote: > We could potentially make close() imply fbarrier(), but there are > plenty of times when that might not be such a great idea. If we do > that, we're back to requiring synchronous data writes for all files on > close() fbarrier() on close() would only mean, that the data shouldn't be written after the metadata and new metadata shouldn't be written _before_ old metadata, so you can also delay the committing of the "dirty" metadata until the real data are written. You don't need synchronous data writes necessarily.
> The fundamental idea here is not all files need to be forced to disk > on close. Not all files need fsync(), or even fbarrier(). An fbarrier() on close() would reflect the thinking of a lot of developers. You might call them stupid and incompetent, but they surely are the majority. When closing A before creating B, they don't expect seeing B without a completed A, even though they might expect that neither A nor B may be written yet, if the system crashes. If you have smart developers, you might give them something new, so they could speed things up with some extra code, e.g. when they create data, which may be restored by other means, but the default behavior of automatic fbarrier() on close() would be better.
Andreas
| |