On Wed, May 22, 2013 at 8:31 AM, thanumalayan mad <[email protected]>wrote:
> > Also, not to spam, but it would be great if you could answer these > questions for my research (you might send me a reply directly without going > through the mailing list): [a] Was it always understood that unlink() and > ftruncate() are not synchronous, and that SQLite transactions in DELETE > mode are not immediately-durable in Linux; or had you initially > misunderstood the semantics of those calls, or left-off the fsync() because > of a typo error? > We are aware of the need to fsync() the directory that contains a file after unlink() in order to make the unlink() durable. We have deliberately chosen to avoid that fsync() for performance reasons. Note that on some systems (ex: AIX and the Chromium sandbox) it is not possible to fsync() a directory and therefore it is not possible to make unlink() durable. > [b] While designing the crash-tests, were the semantics of the calls in > Unix understood? What if ftruncate() not being synchronous did lead to a > consistency-loss? Was it reasoned-out that the non-synchronous ftruncate > would not produce corruption? > Over the past 12 years of developing SQLite, we have become acutely aware of the semantics of unix, both as published and as commonly implemented, which are not necessarily the same thing. Crash-tests are looking for corruption problems only. Crash testing does not look for durability. I do not believe that our crash-testing assumes that ftruncate() is synchronous. Have you detected an error that you have not reported? > [c] How much of a loss in durability (what other than 5 seconds) would be > "good enough" in most cases? > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
