Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AED4A18D53 for ; Mon, 24 Aug 2015 11:49:03 +0000 (UTC) Received: (qmail 45000 invoked by uid 500); 24 Aug 2015 11:48:55 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 44948 invoked by uid 500); 24 Aug 2015 11:48:55 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 44938 invoked by uid 99); 24 Aug 2015 11:48:55 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Aug 2015 11:48:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id B9BB0182100 for ; Mon, 24 Aug 2015 11:48:54 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=daniel.shahaf.name header.b=goOkEXil; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JnjS6emp Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id ldWkGtA3S2sQ for ; Mon, 24 Aug 2015 11:48:50 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 47E2820D30 for ; Mon, 24 Aug 2015 11:48:50 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 82B4F20B75; Mon, 24 Aug 2015 07:48:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 24 Aug 2015 07:48:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=8CGVw524KpOqLQmnuOo0x9rsBAA=; b=goOkEX il6M3vEaykD9PQMuGuGcsboH1RrzkCVWyRtG6R48Dcx7UGenqOLhh5+SQ9RrGoRo eStRGM9JEkLMmFWDm9nz0XzwW8tmguyYQzVB9/4DW9xFhw/DYO7dlbH50KS2ysj+ kfpV6u/CquxfOw1iG3LSs5Xni+RxSD1Bl9SMQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=8CGVw524KpOqLQmnuOo0x9rsBAA=; b=JnjS6 empugskr3qSQhSSufRg0mZ6sC0NsqrEcDhgFmW1TUwl2ZcInhP5HIzPkZBRwFwt9 F8yC2sYhFxO9WxoiUO/tyWLY8zC33JGTSJUtl1t4pMtTBlknuFXNmnk0B1nK8PC0 r/FYtuSmth7babjj/6M0vrIgdLDupnSQmehXQk= X-Sasl-enc: 9XLoRkkJ8vL+uMwlUOWRauRiKbHjT85kOpblkmUMNA8s 1440416929 Received: from tarsus.local2 (bzq-79-183-140-123.red.bezeqint.net [79.183.140.123]) by mail.messagingengine.com (Postfix) with ESMTPA id AA942C00025; Mon, 24 Aug 2015 07:48:48 -0400 (EDT) Date: Mon, 24 Aug 2015 11:48:46 +0000 From: Daniel Shahaf To: Stefan Fuhrmann Cc: Subversion Development Subject: Re: Issue #4588, part 1: FSFS access error Message-ID: <20150824114846.GD7537@tarsus.local2> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Stefan Fuhrmann wrote on Sun, Aug 23, 2015 at 20:38:03 +0100: > This post focuses on the FSFS issue. The good news is that > confidence is high that the repo itself is correct and there > has been no apparent data loss. The error message indicates > that something like Offset=L2P[L2P[Item]] or Offset=L2P[Offset] > instead of Offset=L2P[item] happened. ... > The lookup would start with a hit at the L2 DAG cache, mapping > path+rev onto a noderev. From there, everything is accessed > using physical offsets until some item is not cached. At that > point, we would be trying to use an Offset instead of the Item > index to address the f7 data. Error. So somehow we managed to cast an offset into an item. Can we make the code more strongly-typed? Where is the "L2 DAG cache" in the code? I assume it's ffd->rev_node_cache, not fs_fs_dag_cache_t, correct?