git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric D <eric.decosta@gmail.com>
To: Jeff Hostetler <git@jeffhostetler.com>
Cc: git@vger.kernel.org
Subject: Re: Option to allow fsmonitor to run against repos on network file systems
Date: Mon, 8 Aug 2022 17:58:40 -0400	[thread overview]
Message-ID: <CAMxJVdH+_xJc0VmRkaepww+gQH_==7wf3F8tX4hi99gWVTXCnQ@mail.gmail.com> (raw)
In-Reply-To: <16832f8a-c582-23bb-dda9-b7b2597a42eb@jeffhostetler.com>

On Fri, Jul 1, 2022 at 9:32 AM Jeff Hostetler <git@jeffhostetler.com> wrote:
>
>
>
> On 6/30/22 1:11 PM, Eric D wrote:
> > I can appreciate the concerns expressed here:
> > https://github.com/git/git/commit/d989b266c1a7ef47f27cec75e90f3dfefbfa0200
> >
> > However, in my environment, our file servers are very capable and have
> > the requisite support. It would be great if there was an option to
> > override this check and allow fsmonitor to operate against network
> > filesystems.
>
> Yeah, I was just being cautious.  I probably should have also added
> concerns on the remote system being an actual Windows server or a
> non-Windows host running SAMBA.  There were just too many combinations
> for me to be comfortable enabling it by default (on the initial
> release, at least).
>
> Also, the ReadDirectoryChangesW() API limits the buffer size to 64k
> for remote handles (because of protocol limitations), so there _may_
> be more of an opportunity for dropped events on very busy remote file
> systems.  (I never saw any dropped events in my testing (without
> intentionally breaking things), but it is a possible concern, so again,
> caution and safety...)  And I do handle dropped events and force a
> resync and send the client a "trivial" response (so it must do a regular
> scan), so output is still correct, but slower.
>
>
> Having said all of that, I did do lots of testing and never had an
> issue with remote drives actually working correctly, so I think it'd
> be fine allow a config setting to optionally allow it.  I just didn't
> want to clutter up things in advance if no one actually wanted to
> use it on remote file systems.
>
>
> I think it would be fine to have a "fsmonitor.allowRemote" or
> "fsmonitor.allowWindowsRemote" config setting and default them to false
> for now.  Or until we learn which combinations of remote mounts are
> safe and/or problematic.
>
> Jeff

OK, based on this and other conversations, I have implemented the following:

1. Introduced a new config setting, "fsmonitor.allowRemote"
"fsmonitor.allowRemote" has a default value of false. Setting it to
true overrides
fsmonitor's default behavior of rejecting network-mounted repos.

2. Restricted allowing remote repos to Windows clients using SMB
If the client is not using SMB and using a network path, then
fsmonitor will reject
the repo path regardless of the value of "fsmonitor.allowRemote"

-Eric

      parent reply	other threads:[~2022-08-08 21:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30 17:11 Option to allow fsmonitor to run against repos on network file systems Eric D
2022-07-01 13:32 ` Jeff Hostetler
2022-07-01 18:41   ` Junio C Hamano
2022-07-01 19:15     ` Eric D
2022-08-01 18:35       ` Eric D
2022-08-08 21:58   ` Eric D [this message]

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='CAMxJVdH+_xJc0VmRkaepww+gQH_==7wf3F8tX4hi99gWVTXCnQ@mail.gmail.com' \
    --to=eric.decosta@gmail.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).