Re: hosting git on a nfs
- From
- J. Bruce Fields <bfields@fieldses.org>
- Date
- Nov 13, 2008, 18:18 UTC
- Message-ID
- <20081113181826.GA16741@fieldses.org>
- In-Reply-To
- <alpine.LFD.2.00.0811120959050.3468@nehalem.linux-foundation.org>
On Wed, Nov 12, 2008 at 10:14:44AM -0800, Linus Torvalds wrote:
Show 12 quoted lines
> > > On Wed, 12 Nov 2008, David Brown wrote: > > > > We had occasionally run into locking problems with 1.5.4.x with > > renames between different directories. This should be fixed in > > 1.6.0.3, but we have since migrated to a server model so I don't have > > any way of testing this. > > I suspect it also depends very much on the particular client/server > combination. Renaming across directories is one of those NFS things that > some servers don't mind at all.
On the linux server you want to make sure you're exporting with no_subtree_check (see "man exports").
Show 17 quoted lines
> > The configuration we did find completely unworkable was using git with > > the work tree on NFS. > > Doing an 'lstat()' on every single file in the tree would tend to do that > to you, yes. Even with a fast network and a good NFS server, we're talking > millisecond-range latencies, and if your tree has tens of thousands of > files, you're going to have each "git diff" take several seconds. > > NFS metadata caching can help, but not all clients do it, and even clients > that _do_ do it tend to have rather low timeouts or rather limited cache > sizes, so doing "git diff" twice may speed up the second one only if it's > done really back-to-back - if even then. > > And once you get used to "git diff" being instantaneous, I don't think > anybody is ever agan willing to go back to it taking "a few seconds" (and > depending on speed of network/server and size of project, the "few" can be > quite many ;)
Yep.
Show 5 quoted lines
> So putting the work-tree on NFS certainly _works_, but yes, from a > performance angle it is going to be really irritatingly slower. I don't > even think the newer versions of NFS will help with directory and > attribute caching - the delegations are per-file afaik, and there is no > good support for extending the caching to directories.
File delegations do cover a file's attributes, so in theory they could help. But they're only given out on open. The upcoming 4.1 spec has a few improvements here, and it might be worth looking at whether they're sufficient to make this work.
--b.
Show 11 quoted lines
> That said, I don't think git is any _worse_ than anybody else in the > "worktree on NFS" model. A "git diff" will still be superior ot a CVS diff > in every way. It's just that when people compare to their home machines > where they have the work tree on local disk and aggressively cached, when > they then use a NFS work-tree, they'll likely be very very disappointed. > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html