You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Keith Bostic <ke...@oracle.com> on 2006/06/28 18:57:54 UTC
[PATCH] Re: BerkeleyDb on NetApp NFS [#14837]
The current wording at:
http://subversion.tigris.org/faq.html#nfs
If you are using a repository with the Berkeley DB back end (default
for repositories created with Subversion 1.0 and 1.1, not the default
thereafter), do not access the repository via NFS. Berkeley DB does
not support storage of databases on remote file systems. Some NFS
servers claim that they explicitly support use of Berkeley DB on NFS-
mounted partitions, but we've only ever seen Berkeley DB databases
get corrupted when living on an NFS or SMB network drive.
Isn't quite correct.
Berkeley DB does support database and log file storage on NFS
filesystems, but Subversion cannot take advantage of that because at
least some Subversion commands ('svnadmin list-dblogs', 'svnadmin
list-unused-dblogs', 'svnadmin hotcopy') assume that databases and
log files are in the same directory as the Berkeley DB shared region
files.
As far as corruption goes, the only Berkeley DB corruption of which
I'm aware with respect to Subversion repositories was the corruption
caused by failure to run recovery appropriate on the databases, which
was fixed earlier this year.
I'd suggest the following wording:
If you are using a repository with the Berkeley DB back end (default
for repositories created with Subversion 1.0 and 1.1, not the default
thereafter), do not access the repository via NFS. Althought Berkeley
DB supports database storage on remote file systems, not all
Subversion functionality with be available in this configuration.
Thanks!
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic
+1-781-259-3139
keithbosticim (ymsgid)
keith.bostic@oracle.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Re: BerkeleyDb on NetApp NFS [#14837]
Posted by "C. Michael Pilato" <cm...@collab.net>.
Keith Bostic wrote:
> How about:
>
> If you are using a repository with the Berkeley DB back end (default
> for repositories created with Subversion 1.0 and 1.1, not the default
> thereafter), we do not recommend storing the repository on a remote
> filesystem (for example, NFS). While Berkeley DB databases and log
> files can be stored on remote filesystems, the Berkeley DB shared
> region files cannot be stored on a remote filesystem, the remote
> filesystem is only accessible to a single filesystem client, and not
> all Subversion functionality will be available for the repository.
Committed (with small tweaks) in r20297. Should be reflected on the live
site soonishly.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [PATCH] Re: BerkeleyDb on NetApp NFS [#14837]
Posted by Keith Bostic <ke...@oracle.com>.
On Jun 28, 2006, at 4:00 PM, C. Michael Pilato wrote:
> Keith Bostic wrote:
>> I'd suggest the following wording:
>>
>> If you are using a repository with the Berkeley DB back end (default
>> for repositories created with Subversion 1.0 and 1.1, not the default
>> thereafter), do not access the repository via NFS. Althought Berkeley
>> DB supports database storage on remote file systems, not all
>> Subversion
>> functionality with be available in this configuration.
>
> Hrm. "Not all Subversion functionality will be available" seems a bit
> vague, and still leads folks to believe that there's some
> Subversion-related
> value to be had in putting their BDB-backed repositories on NFS (of
> which I
> can fathom none). I think the key points to make here are:
>
> * you CANNOT safely access an NFS-hosted Subversion repository from
> multiple NFS clients, period.
Agreed. (Well, unless all of the databases are read-only, but you
still need local directories for the shared region files.)
> * you CAN safely access an NFS-hosted Subversion repository from
> a single
> NFS client if, and only if, the NFS implementation is up to
> par. (What
> was the criteria, here -- ability to support file-backed
> shared memory
> regions, or something?)
You can move Berkeley DB databases and log files to a remote
filesystem, as long as sync works, that is, as long as you can flush
to the disk. I don't know of any current NFS implementations where
that's not the case.
You can move Berkeley DB shared region files to a remote filesystem
if the filesystem supports mapping files into process memory (some
do), and supports correct semantics for mutexes in the shared memory
if the mapping succeeds (almost none do).
> * you CAN configure your repository to house its database and
> logfiles
> on NFS, but some Subversion functionality won't work (due to
> shortcomings in Subversion). And of course, since the repository
> itself isn't on NFS, it isn't accessible via any NFS clients.
How about:
If you are using a repository with the Berkeley DB back end (default
for repositories created with Subversion 1.0 and 1.1, not the default
thereafter), we do not recommend storing the repository on a remote
filesystem (for example, NFS). While Berkeley DB databases and log
files can be stored on remote filesystems, the Berkeley DB shared
region files cannot be stored on a remote filesystem, the remote
filesystem is only accessible to a single filesystem client, and not
all Subversion functionality will be available for the repository.
--keith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Re: BerkeleyDb on NetApp NFS [#14837]
Posted by "C. Michael Pilato" <cm...@collab.net>.
Keith Bostic wrote:
> I'd suggest the following wording:
>
> If you are using a repository with the Berkeley DB back end (default
> for repositories created with Subversion 1.0 and 1.1, not the default
> thereafter), do not access the repository via NFS. Althought Berkeley
> DB supports database storage on remote file systems, not all Subversion
> functionality with be available in this configuration.
Hrm. "Not all Subversion functionality will be available" seems a bit
vague, and still leads folks to believe that there's some Subversion-related
value to be had in putting their BDB-backed repositories on NFS (of which I
can fathom none). I think the key points to make here are:
* you CANNOT safely access an NFS-hosted Subversion repository from
multiple NFS clients, period.
* you CAN safely access an NFS-hosted Subversion repository from a single
NFS client if, and only if, the NFS implementation is up to par. (What
was the criteria, here -- ability to support file-backed shared memory
regions, or something?)
* you CAN configure your repository to house its database and logfiles
on NFS, but some Subversion functionality won't work (due to
shortcomings in Subversion). And of course, since the repository
itself isn't on NFS, it isn't accessible via any NFS clients.
Thoughts?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org