Les Mikesell wrote on Thu, Jun 30, 2011 at 11:26:36 -0500: > On 6/30/2011 10:39 AM, Daniel Shahaf wrote: > > > >>>Read the attached issue. FSFS on 1.7 is affected --- specifically, > >>>revprops.db, which contains the only copy of revprops of packed > >>>revisions. > >> > >>A backup made in an inconsistent state should exactly resemble the > >>disk files if the system lost power or crashed for another reason at > >>that point. What are you supposed to do in that very likely > >>circumstance? > > > >SQLite guarantees ACID in the event of a power failure. Given that, > >what do you think FSFS should do to handle a power failure during > >a revprop edit? > > What has to happen to make the system consistent? Whether the > change completes or not only matters if the client records the > success and behaves differently later. >
>From memory, SQLite will rollback the journal on first db access. Read sqlite.org docs for the definitive answer. If power fails, it's possible that a pre-revprop-change will have run without a revprop change having taken place, or that a revprop change has taken place but the post-revprop-change had not (and would not) been run. > >When you say "backup", do you mean "An atomic snapshot of the disk's > >state", 'cp -a', or something else? > > I guess I'm really talking about the state of the disk after the > restore of a filesystem backup. To me, that would usually be an > rsync-based copy which isn't atomic at all but if it is repeated > until it doesn't report any changes I expect it to represent a > consistent state - and generally I expect it to work anyway. On most > filesystems on most hardware, I don't have any particular > expectations about the filesystem state after a crash. Things that > appeared consistent when accessed through the running filesystem > cache may not have been committed to disk or that may have happened > in a different order than expected. > I trust both the FSFS authors and the SQLite authors to be aware both of disk caching and of how to tell the OS "Make sure the data /really/ is on disk". > -- > Les Mikesell > lesmikes...@gmail.com > >
