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.
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.
--
Les Mikesell
lesmikes...@gmail.com
