Re: broken mandatory locking behavior

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

 



On Wed, Oct 05, 2011 at 06:09:36AM -0400, Jeff Layton wrote:
> On Wed, 5 Oct 2011 13:24:59 +0400
> Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote:
> 
> > 2011/10/4 J. Bruce Fields <bfields@xxxxxxxxxxxx>:
> > > On Tue, Oct 04, 2011 at 06:54:51AM -0400, Jeff Layton wrote:
> > >> I think this is tantamount to insisting that applications be specially
> > >> written for cifs.ko if they want to do locking.
> > >>
> > >> The larger goal for cifs.ko (as I see it) is to allow applications to
> > >> mostly run unchanged on top of windows servers. Naturally, this is
> > >> impossible since windows doesn't follow POSIX semantics, so the best we
> > >> can do is closely approximate it.
> > >>
> > >> There's certainly room for improvement here, but what you're proposing
> > >> sounds like a step backward from that goal. It will break a lot of
> > >> existing applications that run successfully on top of cifs.ko today.
> > >
> > > Right.  You can tell which kind of locking the application wants by the
> > > interface it's using.  If the application is using fcntl F_GETLK,
> > > F_SETLK, F_SETLKW, then chances are it was written assuming posix
> > > semantics, so all we can do is emulate those as best as possible.
> > >
> > > If there are applications that need want the Windows semantics, then
> > > we'd need to provide a new lock interface which promises them exactly
> > > that.
> > >
> > > --b.
> > >
> > 
> > Ok, I understand your and Jeff's idea - it's better to support POSIX
> > at least partly than doesn't support it at all.
> > 
> > I don't think that we need VFS changes for the new mode, because it is
> > cifs feature only. All that we need is to support this for cifs - so,
> > it can be a new mount option or the existing one - now we have
> > 'forcemand' mount option (that switch on mandatory locking even if the
> > server support POSIX one) that can includes such a change. What do you
> > think about it?
> > 
> 
> I'm not a fan of adding more mount-option enabled hacks to cifs to
> support wine. If wine or other applications need windows semantics,
> then I would prefer to see you add proper vfs-level interfaces to
> provide them.

Agreed.  A mount option that changes semantics in subtle ways will cause
applications to fail in sutble and unpredictable ways when it's set
wrong.  And doesn't have any hope of handling the case of a mixture of
POSIX and Windows applications on the same filesystem.

Whereas a new interface, when it's unavailable, will cause a clean
predictable failure right at the start, allowing the application to give
a helpful error message, or fall back on different behavior if it
chooses to.

Also, before building anything more on top of Linux mandatory locking,
somebody should really fix the existing bugs--the current implementation
has races.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux