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
> lesmikesell_at_gmail.com
>
>
Received on 2011-06-30 20:15:55 CEST