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 1D3F810316 for ; Tue, 26 May 2015 21:16:29 +0000 (UTC) Received: (qmail 29441 invoked by uid 500); 26 May 2015 21:16:29 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 29392 invoked by uid 500); 26 May 2015 21:16:28 -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 29382 invoked by uid 99); 26 May 2015 21:16:28 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 May 2015 21:16:28 +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 296EE182757 for ; Tue, 26 May 2015 21:16:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 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, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZuFJpGXJStqz for ; Tue, 26 May 2015 21:16:27 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id C862D20FEE for ; Tue, 26 May 2015 21:16:26 +0000 (UTC) Received: by wicmx19 with SMTP id mx19so76407787wic.0 for ; Tue, 26 May 2015 14:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=j3MVrGY4u6x5imeShvXzks6c27BuBdRFFr5139TZPug=; b=Krmua4FbCJGkjy8fVhTzPsL2+1BOK0vcO/oByFBHD+Uic2VLHXb9VtfoBKky+10Zct 2JKPWFUPwsoW2hVZ9Kmmu1Ks4wIpKIBXudntkmhYDA1SGgySd8qivL5/wgnTcxx/gdxF hx/zqvqm8jKVkuQRYfQJFnmq6q+Sp6FEwqVjqzwKfTeM+UZmu7GIbGlQO7KOSmS7m9aW jUElgMvBSFYrzNR3OzNsmTLppQSSO44M+aCpdb/GAbJrTt0fKR86mo5kE9B6ECl9eFrX L3cXHs0BLTpE7G8e7lFtq+fZUkg9HcK2JkvvD5m9i58FGWmltm4cR9Z2mmtSWB1lYOTV RZCQ== X-Received: by 10.180.95.10 with SMTP id dg10mr45085666wib.41.1432674941551; Tue, 26 May 2015 14:15:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.51.38 with HTTP; Tue, 26 May 2015 14:15:21 -0700 (PDT) From: Julian Foad Date: Tue, 26 May 2015 22:15:21 +0100 Message-ID: Subject: Queries about rep cache: get_shared_rep() To: dev Content-Type: text/plain; charset=UTF-8 Index: subversion/libsvn_fs_fs/transaction.c =================================================================== --- subversion/libsvn_fs_fs/transaction.c (revision 1681856) +++ subversion/libsvn_fs_fs/transaction.c (working copy) @@ -2243,12 +2243,14 @@ (representation_t **old_re const char *file_name = path_txn_sha1(fs, &rep->txn_id, rep->sha1_digest, scratch_pool); /* in our txn, is there a rep file named with the wanted SHA1? If so, read it and use that rep. */ + /* ### Would it be faster (and so better) to just try reading it, + and handle ENOENT, instead of first checking for presence? */ SVN_ERR(svn_io_check_path(file_name, &kind, scratch_pool)); if (kind == svn_node_file) { svn_stringbuf_t *rep_string; SVN_ERR(svn_stringbuf_from_file2(&rep_string, file_name, scratch_pool)); @@ -2262,14 +2264,20 @@ get_shared_rep(representation_t **old_re /* A simple guard against general rep-cache induced corruption. */ if ((*old_rep)->expanded_size != rep->expanded_size) { /* Make the problem show up in the server log. - Because not sharing reps is always a save option, + Because not sharing reps is always a safe option, terminating the request would be inappropriate. + + ### [JAF] Why should we assume the cache is corrupt rather than the + new rep is corrupt? Is this really the logic we want? + + Should we do something more forceful -- flag the cache as + unusable, perhaps -- rather than just logging a warning? */ svn_checksum_t checksum; checksum.digest = rep->sha1_digest; checksum.kind = svn_checksum_sha1; err = svn_error_createf(SVN_ERR_FS_CORRUPT, NULL, - Julian