You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@gmail.com> on 2015/10/09 17:16:30 UTC

FAQ about using NFS

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?

Anyone want to take a shot at revising this FAQ answer?

- Julian

Re: FAQ about using NFS

Posted by Stefan Kueng <to...@gmail.com>.

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

Re: FAQ about using NFS

Posted by Branko Čibej <br...@apache.org>.
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.

-- Brane