Re: [PATCH] fsmonitor: option to allow fsmonitor to run against network-mounted repos

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 10, 2022 at 4:36 PM Eric D <eric.decosta@xxxxxxxxx> wrote:
>
> On Wed, Aug 10, 2022 at 3:50 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >
> > Eric D <eric.decosta@xxxxxxxxx> writes:
> >
> > > Makes sense. How about FSMONITOR_OVERRIDE_REQUIRED ? The error message
> > > could then indicate that remote repos are normally unsupported but
> > > that setting the fsmonitor.allowRemote flag overrides this behavior.
> >
> > I actually think check_allow_remote() should be renamed to have
> > "config" somewhere in its name, and return -1, 0 or 1 and not "enum
> > fsmonitor_reason".
> >
> >         static int check_config_allowremote(...)
> >         {
> >                 int allow;
> >
> >                 if (repor_config_get_bool(..., &allow))
> >                         return allow;
> >                 return -1; /* undecided */
> >         }
> >
> > then caller can do
> >
> >         switch (check_config_allowremote(...)) {
> >         case 0: /* config overrides and disables */
> >                 return FSMONITOR_REASON_REMOTE;
> >         case 1: /* config overrides and enables */
> >                 return FSMONITOR_REASON_OK;
> >         default:
> >                 break; /* config has no opinion */
> >         }
> >         return check_smb(...);
> >
> > > If we do as you suggest above, then fsmonitor.allowRemote=true would
> > > override regardless of the protocol being used.
> >
> > Exactly.  The code should not try to outsmart the user.
> >
> > If the user says they wants to use it on a particular remote, even
> > if you do not know if that particular remote system works, just let
> > them try and see if it works.  If it does not, they can easily
> > disable, because the enabiling was a deliberate act by them in the
> > first place.  They know how to fix it.
> >
> > Thanks.
> >
>
> 100% agree with you, thanks.

The only thing that is somewhat gnawing at me is that just because the
remote worktree is mounted via SMB is no guarantee that fsmonitor will
work correctly. In many (most?) cases it should, but who knows what
support the filer server has.

I think we should allow the user to override regardless - as you said
let the user try it. But, conservatively, just because SMB is there
may not be enough to let the monitor start without the explicit user
override. Being able to report on which protocol is being used could
provide useful diagnostics, but that's about it.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux