> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: donderdag 15 oktober 2015 19:40
> To: Branko Čibej <brane_at_apache.org>
> Cc: dev_at_subversion.apache.org
> Subject: Re: NFS performance regression in 1.9
>
> Branko Čibej <brane_at_apache.org> writes:
>
> > And in another thread (on IRC, I think) we talked about not recommending
> > NFS because it's not reliable given our requirement for atomic renames.
>
> Lots of people, including Subversion developers, use working copies on
> NFS successfully. It may not be perfect but it works well enough in
> lots of cases. Pointing out potential pitfalls is fine, any sort of
> blanket ban would be odd. Repositories on NFS might be more vulnerable.
>
> I think the usual problem for NFS rename is that while the underlying
> filesystem implements an atomic rename the mechanism that reports back
> to the client may fail. Such an error may cause the client to exit with
> an error but the working copy itself is probably OK.
>
> All filesystems can have bugs. How likely is NFS to fail for a typical
> user of Subversion working copies on NFS? Is NFS less reliable than a
> local filesystem that uses LVM+mdadm+ZFS/BtrFS? Is NFS less reliable
> than the firmware in a h/w RAID card?
I'm not able to answer all that, but I do know that your change will slow Subversion down on Samba shares as used from Windows systems with that flag. And once one user used it in that way it will stay slow because the journal mode is stored in the database.
I don't think just touching a working copy with a client should ever have such an effect on a working copy.
Bert
Received on 2015-10-15 20:21:23 CEST