Re: Severe I/O performance regression 2.6.6 to 2.6.7 or 2.6.8-rc3

From: Andy Isaacson (adi_at_hexapodia.org)
Date: 08/06/04

  • Next message: Gene Heskett: "Re: Possible dcache BUG" 
    Date:	Thu, 5 Aug 2004 21:09:30 -0500
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>

    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Gene Heskett: "Re: Possible dcache BUG"

    Relevant Pages

    • Re: [PATCH] Add notification of page becoming writable to VMA ops [try #3]
      ... It would appear that "The latest snapshot for the stable Linux kernel ... tree" is a bit out of date on www.kernel.org. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Severe I/O performance regression 2.6.6 to 2.6.7 or 2.6.8-rc3
      ... > guaranteed that your tree state matches exactly the state of anyone else ... Rather, the snapshot metadata ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: who is merlin.fit.vutbr.cz?
      ... > Locking on reads prevents getting a copy of the tree with half of someone ... Or, without such snapshot feature, after reading the entire tree unlocked, ... And then the C programmer became enlightened... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [ANNOUNCE] udev 006 release
      ... >> If anyone ever wants a snapshot of the current tree, ... >> BitKeeper, or other reasons, is always available at any time by asking. ... Daily tarballs of udev as well as a daily unpacked tree can now also ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)