mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Eric D. Mudama" <edmudama@mail.bounceswoosh.org>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.6.0 - Watchdog patches (BK consistency checks)
Date: Wed, 31 Dec 2003 10:42:06 -0700	[thread overview]
Message-ID: <20031231174206.GA14338@bounceswoosh.org> (raw)
In-Reply-To: <200312311001.48154.edt@aei.ca>

On Wed, Dec 31 at 10:01, Ed Tomlinson wrote:
>I am not saying I do not want do have consistency checks done.  I do want
>to control _when_ and how often they run

I don't see how it would be valid to not do a consistency check after
every network operation, which is what it does now...

Every time you are modifying your archive from a remote source, the
consistency check makes sure you don't have corruption in the transfer
that was previously undetected, or corruption in the underlying
archive which is about to accept the changes.  Since you can only do
network updates at a time when your own archive is in a "checked-in"
state, if the network update fails or detects corruption, you can
clone what you'd already checked in to a new location and recover
trivially.  The most work you can lose is the delta between your last
changeset and the current one, assuming you keep some sort of backups
around.

What exactly would you do if you'd been working "offline" for 3 weeks,
went to sync, and it said that your archive was corrupted?  Or should
it try to merge into a corrupt archive anyway?  Should that archive
that was corrupt, and then had possibly good changes layered on top of
it, be valid for attempting a clone?

I think that limiting the consistency checking could be like opening a
*very big* can of worms.




-- 
Eric D. Mudama
edmudama@mail.bounceswoosh.org


  reply	other threads:[~2003-12-31 17:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-06 10:51 [PATCH] 2.6.0-test4 - Watchdog patches - Documentation Wim Van Sebroeck
2003-12-29 19:52 ` [PATCH] 2.6.0 - Watchdog patches Wim Van Sebroeck
2003-12-29 20:11   ` Linus Torvalds
2003-12-29 20:22     ` Wim Van Sebroeck
2003-12-29 20:30       ` Linus Torvalds
2003-12-30  0:49         ` Matthias Andree
2003-12-30  6:36           ` Linus Torvalds
2003-12-30 13:36           ` [PATCH] 2.6.0 - Watchdog patches (BK consistency checks) Ed Tomlinson
2003-12-30 19:13             ` Andy Isaacson
2003-12-30 19:56               ` Eric D. Mudama
2003-12-30 20:16                 ` Andy Isaacson
2003-12-31 16:33                   ` Ed Tomlinson
2003-12-31 15:01               ` Ed Tomlinson
2003-12-31 17:42                 ` Eric D. Mudama [this message]
2003-12-31 19:13                 ` Andy Isaacson
2003-12-29 20:36     ` [PATCH] 2.6.0 - Watchdog patches Jeff Garzik
2003-12-30 12:14       ` Paul Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031231174206.GA14338@bounceswoosh.org \
    --to=edmudama@mail.bounceswoosh.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®