From: William Lee Irwin III <wli@holomorphy.com>
To: Andy Isaacson <adi@hexapodia.org>
Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.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 19:27:34 -0700 [thread overview]
Message-ID: <20040806022734.GN17188@holomorphy.com> (raw)
In-Reply-To: <20040806020930.GA23072@hexapodia.org>
At some point in the past, I wrote:
>>> 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.
On Thu, Aug 05, 2004 at 09:09:30PM -0500, Andy Isaacson wrote:
> 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.
Once we get there, there must be some way to construct intermediate
points between those two faithful at the very least to the snapshot
ordering if not true chronological ordering.
On Thu, Aug 05, 2004 at 07:33:19PM -0300, Marcelo Tosatti wrote:
>> 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...
On Thu, Aug 05, 2004 at 09:09:30PM -0500, Andy Isaacson wrote:
> 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.
Yes, this would be very helpful.
-- wli
next prev parent reply other threads:[~2004-08-06 2:27 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
2004-08-06 2:27 ` William Lee Irwin III [this message]
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=20040806022734.GN17188@holomorphy.com \
--to=wli@holomorphy.com \
--cc=adi@hexapodia.org \
--cc=berkley@cse.wustl.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.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