No, I have reported everything. The only thing I missed might be that it's not "5 seconds" always, but rather the configurable commit interval of the filesystem, which is by default 5 seconds in most desktop Linux distros.
I only read through the source code of test6.c, and misunderstood that ftruncate() was assumed to be synchronous. Sorry. I still think that test6.c might assume unlink() to be synchronous, though again, that is just a "think". Thanks for the replying to my questions. They are really useful. I am extremely surprised to learn that unlink() cannot be made durable in some systems. Do answer [c] too, if that's possible. I still am examining SQLite and a bunch of other DBMSs for power-crash scenarios, so might come back to badger you about "bugs" in the future. -- Thanumalayan Sankaranarayana Pillai (Graduate student at the University of Wisconsin-Madison) On Wed, May 22, 2013 at 8:05 AM, Richard Hipp <[email protected]> wrote: > > > 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
