On 25.04.2014 23:02, Les Mikesell wrote:
> On Fri, Apr 25, 2014 at 3:26 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>> 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.
> Working copies are supposed to be throwaway things that can always be
> fixed to the last commit by the server. Why wouldn't you want to use
> something fast, cheap, and highly buffered for that, even if it is
> half baked?
Conversely, why would you want to put a throwaway thing on NFS?
To stray off topic for a minute here, though: the idea that working
copies are "cheap throwaway stuff" is less than universally true. I've
seen complex sparse working copies with many gigabytes of data,
containing (unversioned) build artefacts, that take hours or days to
produce ... I wouldn't call that cheap by any definition.
Still, none of the above changes the fact that NFS is not suitable for
high-volume, random-access, read/write applications. It's great for
sharing mostly read-only data, but a Subversion working copy, let alone
repository, does not fall into that category.
Bottom line: you can have fast, or you can have NFS.
-- Brane
P.S.: The argument that 1.6 working copies worked just fine on NFS
doesn't hold water; those were still subject to the non-atomic rename
corruption bug; and, of course, they were an order of magnitude slower
on local storage than the latest releases. We made a conscious decision
to design a working copy format that's faster than the old format could
ever have been and can better support new features (such as client-side
move tracking), at the expense of poorer performance on a remote
filesystem that is, when you get right down to it, a 30-year-old
dinosaur that was never designed for the kind of use that people these
days seem to assume it can support.
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-04-25 23:34:53 CEST