VFS - ENOTSUP vs ENOSYS

[Michael Adam]

On 2015-09-01 at 09:03 -0400, Ira Cooper wrote:
> Michael Adam <obnox at samba.org> writes:
> > On 2015-08-31 at 20:33 -0400, Ira Cooper wrote:
> >> 
> >> I've hit a bug that I'm working on fixing involving kernel share modes,
> >> and vfs modules that don't implement them.
> >> 
> >> But I realized, returning ENOSYS was wrong, because in this case
> >> kernel_flock will implement it on XFS.  But Gluster doesn't support
> >> kernel_flock.  So it should return ENOTSUP not ENOSYS, IMHO.
> >
> > Maybe I am just confused, but looking at the code in open.c,
> > where SMB_VFS_KERNEL_FLOCK is called, we currently have a problem
> > of getting sharing violation for any vfs module that returns
> > -1 from kernel_flock_fn, irrespective of the errno?
> > (The code does not check it.)
> 
> Correct, that's the problem that opened "pandora's box".
> 
> > I have had the impression before, that I can't see
> > how the current glusterfs vfs module can work without
> > 'kernel share modes = no' in the config.
> >
> > Maybe I am also just missing a subtle point.
> 
> The real queston is, are we returning the correct errno.

This will be the real question once we add a patch to
check the errno in case of SMB_VFS_KERNEL_FLOCK() returning -1.
I.e. for which errnos do we change behaviour (from returning
SHARING_VIOLATION to something else).

> I'm not clear on that topic.
> 
> ENOSYS - Implies things will never succeed on this system.

My understanding would be that 'system' in this setting means
the current setup of the vfs module stack and file system
underneath. I.e. once you have connected to a share, you'll
always get this, for all fds, if you get it once, for one fd.

> ENOTSUP - Implies that the feature you requested is not supported in
>           this situation.

Might mean that results may vary at runtime.

> I'll admit the difference seems subtle, but the thing is if you get
> ENOSYS, you can shortcut that check forever. You know the check should
> never work.

Yeah, for a given share connection (i.e. connected vfs stack).

> ENOTSUP implies there may be another fd or whatever where
> it could work.


> Given that we support multiple VFS modules, it is hard for me to see
> many cases where we'd return ENOSYS in reality.
> 
> Now, I do consider this an ABI change, and one which may break modules
> not in tree.  (Will?)
> 
> I'd really like feedback on this before I start looking at how to fix
> it.  ENOTSUP is a proposed errno for this situation.  If people have
> other ideas, I'm all ears.

I think this line of thoughts sounds like a reasonable set of
changes. And if this is how to fix some problems, and this
requires a VFS (ABI) change, then so be it. But that's just me.
;-)

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150903/997f09dc/attachment.sig>