From: Johannes Sixt <j.sixt@viscovery.net>
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: what's the current wisdom on git over NFS/CIFS?
Date: Fri, 03 Jul 2009 08:14:46 +0200 [thread overview]
Message-ID: <4A4DA1D6.40301@viscovery.net> (raw)
In-Reply-To: <2e24e5b90907021752t10243468sc07be88cd88ac5c1@mail.gmail.com>
Sitaram Chamarty schrieb:
> On Fri, Jul 3, 2009 at 2:28 AM, Linus
> Torvalds<torvalds@linux-foundation.org> wrote:
>> Btw, I think we fixed the problem we had with CIFS. That one was a cifs
>> filesystem problem on Linux, but it should be fixed in 2.6.30+ (commit
>> 0f4d634c: "cifs: flush data on any setattr"). If you have an older kernel
>> (or are just uncertain), you can also work around it with
>>
>> [core]
>> fsyncobjectfiles = true
>>
>> which may be a good thing in general (regardless of any cifs issues), but
>> in most cases the performance loss isn't worth it if your filesystem is
>> stable and sane.
>
> Though I asked this following from a debate on IRC, it now looks as if
> this will solve another of my problems too.
>
> Let me explain.
>
> I'm evangelising git at work, and although most projects are happy,
> even eager to setup a proper server for git, and those that can't are
> happy to just use mine, there are a couple of projects that are almost
> exclusively Windows _and_ cannot add another machine _and_ have client
> confidentiality issues so they can't just use my server.
I don't exactly understand why your reply with this Windows story to the
fsyncobjectfiles paragraph. But if you think that fsyncobjectfiles+msysgit
is your killer argument, then you think wrong: fsyncobjectfiles is ignored
in msysgit. (We don't yet have an implementation of fsync() :-( )
The issue that Linus mentioned happened when a Linux client operates in a
repository that lives on a CIFS mount.
> My alternatives for them so far were (1) VirtualBox running Fedora or
> something within one of their beefier Windows servers or (2) the whole
> cygwin install, which is painful compared to msysgit.
>
> Sounds like we can just do it with traditional Windows fileshares, as
> long as we make sure no one does a "git gc" on the bare repo that is
> being shared. That's a very small price to pay!
It will work with the caveat you mention. I have such a setup myself.
-- Hannes
next prev parent reply other threads:[~2009-07-03 6:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 13:11 what's the current wisdom on git over NFS/CIFS? Sitaram Chamarty
2009-07-02 13:58 ` Martin Langhoff
2009-07-02 14:00 ` Martin Langhoff
2009-07-02 20:58 ` Linus Torvalds
2009-07-03 0:52 ` Sitaram Chamarty
2009-07-03 6:14 ` Johannes Sixt [this message]
2009-07-03 6:37 ` Sitaram Chamarty
2009-07-03 8:56 ` Dmitry Potapov
2009-07-03 9:18 ` Johannes Sixt
2009-07-03 16:08 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A4DA1D6.40301@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=sitaramc@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.