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 A5FA71872D for ; Fri, 9 Oct 2015 20:03:25 +0000 (UTC) Received: (qmail 22579 invoked by uid 500); 9 Oct 2015 20:03:16 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 22502 invoked by uid 500); 9 Oct 2015 20:03:16 -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 22421 invoked by uid 99); 9 Oct 2015 20:03:15 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Oct 2015 20:03:15 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 15A3D1A0807 for ; Fri, 9 Oct 2015 20:03:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 4fk2rhm_T0a7 for ; Fri, 9 Oct 2015 20:03:08 +0000 (UTC) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id A31A920F7B for ; Fri, 9 Oct 2015 20:03:07 +0000 (UTC) Received: by wicge5 with SMTP id ge5so82652761wic.0 for ; Fri, 09 Oct 2015 13:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=FO//XDm0BQ/xZm0ewtNDQa39S9fq1oEJE2SpVRy9PWg=; b=qE4LYCCjHcZbihmk1gU3+TU4t4jRAoeJIivLULv5rLAmfZju//UBEHBe7DR/FYjEUe 5R7Zx53zCSR+G1/LKYY7CcH/GOd9LtoR3a7XdiaQ3uPVn20/faWGsjvM2OiyMMqRXZoS W6M4L0pFsD7zDPlFzspmjAsxvQFy+6LxF1yRpQ42HslH4mWGQ5+9aFtdcSavIsGw21Uw /ZaymOci1qUMHw9HO0Yau5X+EkqNXQ28FRU39WYxD54SBnZYVbcGErMfuJcuNUye8PeF nkijNt/FAMB8UhhF4QkU4Vj7gn+lMalufWC3U6eSDzelfh5OUfKAdrdVQ9BklB5j9jWt oeMA== X-Received: by 10.180.107.130 with SMTP id hc2mr1020107wib.92.1444420986336; Fri, 09 Oct 2015 13:03:06 -0700 (PDT) Received: from [192.168.1.124] (cable-static-20-197.rsnweb.ch. [88.84.20.197]) by smtp.googlemail.com with ESMTPSA id uj4sm3905343wjc.34.2015.10.09.13.03.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 13:03:05 -0700 (PDT) Subject: Re: FAQ about using NFS To: dev@subversion.apache.org References: <5617E870.8050104@apache.org> From: Stefan Kueng Message-ID: <56181D82.8020806@gmail.com> Date: Fri, 9 Oct 2015 22:03:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5617E870.8050104@apache.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 09.10.2015 18:16, Branko Čibej wrote: > On 09.10.2015 17:16, Julian Foad wrote: >> This FAQ seems rather out of date / lacking in correctness: >> >> http://subversion.apache.org/faq#nfs >> >> Since 1.7, the SQLite DB in the WC needs 'file locking' to work >> properly, which (as I understand it) sometimes needs to be enabled in >> the NFS server config, and on some NFS implementations (and other >> networked file systems?) doesn't work properly. Is that roughly >> correct? >> >> So the simple message "Working copies can be stored on NFS" needs to >> be amended to say something about the need for locking to work? >> >> What about the "server" parts of the answer? (First, we should move >> the FSFS part to come first, as that's more widely used.) But does >> FSFS with rep-cache just "work fine on modern NFS" as stated? If so, >> is the same true for the WC? > > > Nothing that relies on atomic renames or locking works reliably with > *any* NFS server. AFAIK, while there are solutions for the locking > problems, there are no solutions for making renames atomic. > > That's disregarding the problem of simultaneous remote and local access > to the NFS server's filesystem. That's somewhat less problematic in the > working copy, which is usually accessed only from one client at a time. > But having the repository on NFS and the actual server on possibly > several other machines is a disaster waiting to happen. > > >> Anyone want to take a shot at revising this FAQ answer? > > Rumour and reading a few bits of spec doesn't make me an NFS expert, I'm > afraid. Maybe link to the SQLite FAQ about this: https://www.sqlite.org/faq.html#q5 See the second paragraph under that FAQ entry. I'd say if SQLite does not recommend storing the db file on NFS, Subversion should do the same and not recommend storing working copies on NFS. Stefan