From: Andy Isaacson <adi@hexapodia.org>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: William Lee Irwin III <wli@holomorphy.com>,
"Mr. Berkley Shands" <berkley@cse.wustl.edu>,
linux-kernel@vger.kernel.org
Subject: Re: Severe I/O performance regression 2.6.6 to 2.6.7 or 2.6.8-rc3
Date: Thu, 5 Aug 2004 21:09:30 -0500 [thread overview]
Message-ID: <20040806020930.GA23072@hexapodia.org> (raw)
In-Reply-To: <20040805223319.GA18155@logos.cnet>
On Thu, Aug 05, 2004 at 07:33:19PM -0300, Marcelo Tosatti wrote:
> On Thu, Aug 05, 2004 at 01:46:15PM -0700, William Lee Irwin III wrote:
> > > the problem does not exist using 2.6.6-bk6, but exists on 2.6.6-bk7.
> > > -bk8 and -bk9 faile to build.
> > > these are from patches-2.6.6-bk6 off snapshots/old and applied to a
> > > vanilla 2.6.6 kernel.
> >
> > This is the closest it appears to be possible to narrow down where the
> > regression happened.
> >
> > Some form of changelogging to enumerate what the contents of the
> > 2.6.6-bk6 -> 2.6.6-bk7 delta are and to reconstruct intermediate points
> > between 2.6.6-bk6 and 2.6.6-bk7 is needed.
If you're willing to use bk, it's trivial. Each changeset refers to a
particular state of the tree. If "bk -r check -acv" reports no errors,
and "bk changes -r+ -d:KEY:" reports a particular key, you are
guaranteed that your tree state matches exactly the state of anyone else
who has that key at any point in the past. [1]
So if the -bkX creation script doesn't already, it should "bk changes
-r+ -d:KEY: > key-bk$X" when it creates the tarball. Then anyone can
"bk clone -r`cat key-bk7` linux-2.5 linux-2.6-bk7" and duplicate the
-bk7 state of the tree, and then "bk changes -L ../linux-2.6-bk6" to
find the list of changesets differing.
> Indeed its nasty, the problem is there is no tagging in the main BK repository
> representing the -bk tree's. It shouldnt be too hard to do something about
> this? I can't think of anything which could help...
Tagging isn't the answer for snapshots. Rather, the snapshot metadata
needs to include the cset key at the snapshot instant.
[1] well, caveat -- bk isn't cryptographically secure, so probably a
motivated attacker could construct a tree which would pass this test
but have different contents. This wouldn't allow the attacker to
push invalid contents to other trees, just to have different
contents in their tree.
-andy
next prev parent reply other threads:[~2004-08-06 2:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-05 17:02 Severe I/O performance regression 2.6.6 to 2.6.7 or 2.6.8-rc3 Mr. Berkley Shands
2004-08-05 17:25 ` William Lee Irwin III
2004-08-05 19:58 ` Mr. Berkley Shands
2004-08-05 20:46 ` William Lee Irwin III
2004-08-05 22:33 ` Marcelo Tosatti
2004-08-06 0:21 ` William Lee Irwin III
2004-08-06 2:09 ` Andy Isaacson [this message]
2004-08-06 2:27 ` William Lee Irwin III
2004-08-06 2:42 ` Andy Isaacson
2004-08-06 3:11 ` William Lee Irwin III
2004-08-06 8:33 ` Helge Hafting
2004-08-06 8:51 ` William Lee Irwin III
2004-08-06 18:02 ` Fast patch for " Mr. Berkley Shands
2004-08-08 8:22 ` Ram Pai
2004-08-16 20:30 ` [PATCH] " Ram Pai
-- strict thread matches above, loose matches on Subject: below --
2004-08-06 0:41 Berkley Shands
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=20040806020930.GA23072@hexapodia.org \
--to=adi@hexapodia.org \
--cc=berkley@cse.wustl.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=wli@holomorphy.com \
/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