> From: Les Mikesell [mailto:lesmikes...@gmail.com] > > A filesystem snapshot should present exactly the same scenario as a machine > that > lost power or crashed for some similar reason at that moment, so the question > boils down to whether subversion can recover sensibly from a crash at any > point. > The fsync's are going to be the critical thing for ordering operations at > the > disk level, however there is no guarantee how much of the fsync operation > might > have completed when a crash or snapshot happens.
...and therefore applications (should) make no assumptions about the order of writing, or, in the case of a crash, what data actually was written. In generally, atomic updates have three phases: prepare, commit, apply. In prepare, all changes are written in a manner that either does not touch the main data (journal), or can be undone. In commit, an atomic write marks the prepared data as committed. In apply, changes written in the prepare phase are applied to the main data if required (ie: journal entries are "replayed" to the main database). The only atomic requirement here is that after prepare, we can flush everything (order is not important) and the commit phase can be written atomically. For example, the db/current file is a integer string. Since that file fits in a single disk block, there is no chance that an update to db/current does not leave either the old or the new contents in the file. -- -Justin
