Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of brane@wandisco.com designates
 74.125.83.45 as permitted sender)
Message-ID: <535AC4E0.6050709@wandisco.com>
Date: Fri, 25 Apr 2014 22:26:08 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: users@subversion.apache.org
Subject: Re: Subversion Windows Performance compared to Linux
References: <24735253.225072.1398445768181.JavaMail.root@naumenko.ca>
In-Reply-To: <24735253.225072.1398445768181.JavaMail.root@naumenko.ca>
Content-Type: multipart/alternative;
 boundary="------------030201020407010202030203"

This is a multi-part message in MIME format.
--------------030201020407010202030203
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.04.2014 19:09, Roman Naumenko wrote:
>> That was a known consequence of moving to SQLite for storage of the
>> metadata. SVN 1.8 offers a solution for those that can use it:
>> http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking
> Mark, thank for the link.  There is indeed a nice performance boost to the client with exclusive access.


Anyone who insists on using Subversion on NFS, whether as client or
server, should be aware of two things:

  * File locking is, at best, flaky on NFS (even NFSv4+); and it's
    always slow. This will affect the working copy.
  * NFS does not guarantee that all clients see renames as atomic
    operations, which affects both working copy and repository, and in
    the worst case, can cause corruption. This is more likely if you
    allow both local and remote access to the same files.

In short, no-one should ever assume that NFS behaves as a local file
system; and even less complain when it doesn't. To be fair, CIFS isn't
much better. Furthermore, these limitations and caveats are not specific
to Subversion.

If you absolutely must put your working copies or repositories on
non-local storage, you should use a SAN with a real, multi-homed
distributed filesystem. Anything else is half-baked, at least as far as
data integrity is concerned.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

--------------030201020407010202030203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 25.04.2014 19:09, Roman Naumenko
      wrote:<br>
    </div>
    <blockquote
      cite="mid:24735253.225072.1398445768181.JavaMail.root@naumenko.ca"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">That was a known consequence of moving to SQLite for storage of the
metadata. SVN 1.8 offers a solution for those that can use it:
</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap=""><a class="moz-txt-link-freetext" href="http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking">http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking</a>
</pre>
      </blockquote>
      <pre wrap="">
Mark, thank for the link.  There is indeed a nice performance boost to the client with exclusive access.</pre>
    </blockquote>
    <br>
    <br>
    Anyone who insists on using Subversion on NFS, whether as client or
    server, should be aware of two things:<br>
    <ul>
      <li>File locking is, at best, flaky on NFS (even NFSv4+); and it's
        always slow. This will affect the working copy.</li>
      <li>NFS does not guarantee that all clients see renames as atomic
        operations, which affects both working copy and repository, and
        in the worst case, can cause corruption. This is more likely if
        you allow both local and remote access to the same files.<br>
      </li>
    </ul>
    <p>In short, no-one should ever assume that NFS behaves as a local
      file system; and even less complain when it doesn't. To be fair,
      CIFS isn't much better. Furthermore, these limitations and caveats
      are not specific to Subversion.<br>
    </p>
    If you absolutely must put your working copies or repositories on
    non-local storage, you should use a SAN with a real, multi-homed
    distributed filesystem. Anything else is half-baked, at least as far
    as data integrity is concerned.<br>
    <br>
    -- Brane<br>
    <br>
    <div class="moz-signature">-- <br>
      <span style="font-face:sans-serif;font-size:9pt;line-height:18pt">Branko
        Čibej <span style="color: #f90">|</span> <span
          style="font-weight:bold">Director of Subversion</span>
        <br>
        WANdisco <span style="color: #f90">//</span> <span
          style="font-style:oblique">Non-Stop Data</span>
        <br>
        <span style="color: #ccc">e.</span> <a class="moz-txt-link-abbreviated" href="mailto:brane@wandisco.com">brane@wandisco.com</a></span></div>
  </body>
</html>

--------------030201020407010202030203--