You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hans P. Reiser" <re...@cs.fau.de> on 2005/08/18 08:04:40 UTC
Working copy on a NFS server problem.
The FAQ states that a working copy on NFS server works, and suggests
disabling subtree checking if it does not. As it did not work in my
environment, and disabling subtree checking was not an option, I
tracked down the problem a bit closer:
Having a working copy on a NFS server that re-uses filehanles (like unfsd)
failes. You might consider such a NFS server broken, or you might consider
the NFS client broken, as it writes the content of a deleted file to the
newly created file if the new one reuses the filehandle of the deleted
one (and if less data is written to the new file than the deleted one
contained, garbage will remain at the end of the file which causes
subversion's famous XML parsing error messages).
See also http://bugzilla.kernel.org/show_bug.cgi?id=5085
Subversion could use a simple workaround for such broken systems by
calling ftruncate with size 0 after creating a new file. Any chance
for such a subversion modification? As this question is already
highlighted with a red box in the FAQ, it is surely a frequent
issue. A workaround for the problem in subversion might be a faster
solution than waiting for a potential modifiction of NFS client or
server behaviour.
Best regards,
Hans P. Reiser
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Working copy on a NFS server problem.
Posted by Ben Collins-Sussman <su...@collab.net>.
Subversion doesn't do disk i/o calls directly, it's all being done
through APR. I wonder if it's possible for us to tell APR to do this...
On Aug 18, 2005, at 3:04 AM, Hans P. Reiser wrote:
>
> The FAQ states that a working copy on NFS server works, and suggests
> disabling subtree checking if it does not. As it did not work in my
> environment, and disabling subtree checking was not an option, I
> tracked down the problem a bit closer:
>
> Having a working copy on a NFS server that re-uses filehanles (like
> unfsd)
> failes. You might consider such a NFS server broken, or you might
> consider
> the NFS client broken, as it writes the content of a deleted file
> to the
> newly created file if the new one reuses the filehandle of the deleted
> one (and if less data is written to the new file than the deleted one
> contained, garbage will remain at the end of the file which causes
> subversion's famous XML parsing error messages).
> See also http://bugzilla.kernel.org/show_bug.cgi?id=5085
>
> Subversion could use a simple workaround for such broken systems by
> calling ftruncate with size 0 after creating a new file. Any chance
> for such a subversion modification? As this question is already
> highlighted with a red box in the FAQ, it is surely a frequent
> issue. A workaround for the problem in subversion might be a faster
> solution than waiting for a potential modifiction of NFS client or
> server behaviour.
>
> Best regards,
>
> Hans P. Reiser
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Working copy on a NFS server problem.
Posted by Mark Phippard <Ma...@softlanding.com>.
Greg Hudson <gh...@MIT.EDU> wrote on 08/18/2005 10:09:17 AM:
> > As this question is already
> > highlighted with a red box in the FAQ, it is surely a frequent
> > issue.
>
> I just looked at the FAQ and couldn't find a red box
The red box is just a generic part of the FAQ style sheet when you have
clicked on an anchor to view the FAQ. For example, use this link in your
browser and you will see the red box:
http://subversion.tigris.org/faq.html#nfs
Use this link and just scroll down to the FAQ and there is no red box.
http://subversion.tigris.org/faq.html
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Working copy on a NFS server problem.
Posted by "Hans P. Reiser" <re...@cs.fau.de>.
> I just looked at the FAQ and couldn't find a red box, nor did the
Sorry for the misinterpretion, it is just the Browser that renders
the http://subversion.tigris.org/faq.html#nfs with such a box.
> question about NFS refer to XML parse errors. So I'm a bit skeptical
> that this is a frequent issue.
I did a Google search when I first encountered the problem, which
revealed no solutions, but indeed at some other persons suffering
from the same problem.
http://list.cs.brown.edu/pipermail/plt-scheme/2005-May/008964.html
http://svn.haxx.se/users/archive-2005-03/0978.shtml
http://svn.haxx.se/users/archive-2005-06/0462.shtml
> This would be a pretty easy workaround for us since file opens are
> funneled through svn_io_file_open(). But it's always a bit dangerous to
> introduce such workarounds into an application if the benefit is
> marginal. It leeches performance from everyone else, and it's hard to
> tell when we get to remove the workaround without creating a regression.
It is rather frustrating at first if you get strange "Malformed XML"
errors from svn without a clue what's going wron. If the problem is
not frequent enough for a workaround in svn, maybe it should at least
be documented in the FAQ.
Anyway, many thanks for the hint to svn_io_file_open. Locally patching
subversion/libsvn_subr/io.c this way works as a charm for me:
--- io-orig.c 2005-08-18 18:00:53.000000000 +0200
+++ io.c 2005-08-18 17:53:25.000000000 +0200
@@ -2121,4 +2121,7 @@
status = apr_file_open (new_file, fname_apr, flag, perm, pool);
+ if ((flag & APR_CREATE) && (flag & APR_EXCL)) {
+ apr_file_trunc(*new_file, 0);
+ }
if (status)
return svn_error_wrap_apr (status, _("Can't open file '%s'"),
Best regards,
Hans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Working copy on a NFS server problem.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-08-18 at 10:04 +0200, Hans P. Reiser wrote:
> The FAQ states that a working copy on NFS server works, and suggests
> disabling subtree checking if it does not. As it did not work in my
> environment, and disabling subtree checking was not an option, I
> tracked down the problem a bit closer:
Fascinating. I'm surprised that a filesystem problem of this magnitude
would be primarily noticeable in Subversion, and not in a host of other
cases.
> Subversion could use a simple workaround for such broken systems by
> calling ftruncate with size 0 after creating a new file. Any chance
> for such a subversion modification? As this question is already
> highlighted with a red box in the FAQ, it is surely a frequent
> issue.
I just looked at the FAQ and couldn't find a red box, nor did the
question about NFS refer to XML parse errors. So I'm a bit skeptical
that this is a frequent issue.
This would be a pretty easy workaround for us since file opens are
funneled through svn_io_file_open(). But it's always a bit dangerous to
introduce such workarounds into an application if the benefit is
marginal. It leeches performance from everyone else, and it's hard to
tell when we get to remove the workaround without creating a regression.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org