On 29-Jun-07, at 6:45 PM, Andreas Hasenack wrote:
> On Fri, Jun 29, 2007 at 05:17:36PM -0300, Toby Thain wrote:
>> When was the last time your fsck reported corruption, and did you
>> find the
>> root cause?
>
> Sure, an unexpected shutdown for example. I'm glad such a minor event
> didn't force me to reinstall the whole operating system or restore
> from
> backups. You don't expect me to have a diesel generator around
> here, do
> you? :)
Yes, it will usually be an unexpected shutdown.
Which is why fsck is not a very good analogy: Because it's certainly
possible (viz. ZFS, Reiser3, etc) to design a database/filesystem/
repository whose integrity is not risked by "unexpected shutdown" -
in a word, transactional. (Obviating fsck!) And I suspect this is not
lost on the Subversion designers, given that Svn is transactional by
design, a property which must be based on the underlying data store.
Which is why I said that some structural design effort up front - if,
for example, it is desired behaviour to "stay consistent in the face
of unexpected interruption" - is likely to be a better investment
than a post-facto scavenger.
(Of course, if the design is *not* transactional (and I have no
evidence that Subversion+FSFS/BDB is not), then there could be
identifiable failure modes in the particular case of *interruption*
which could be addressed by an fsck-like scavenger. However, the
thread has not been discussing this special case, but rather
*arbitrary* hardware faults. "Unexpected interruption" is perhaps the
simplest and least destructive unexpected event of all.)
Another difference between software and hardware faults: A software
problem may *never* be encountered in your use of Subversion (of
course it has >0 bugs, but you may simply never step on one); but a
hardware problem is statistically *inevitable*.
Bottom line: Carefully characterise what you want to defend against.
--Toby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jun 30 01:12:16 2007