[linux-cifs-client] [PATCH 0/3] cifs: some random patches for 2.6.31

Jeff Layton jlayton at redhat.com
Mon May 25 17:59:28 GMT 2009


On Mon, 25 May 2009 13:56:40 -0400
simo <idra at samba.org> wrote:

> On Mon, 2009-05-25 at 13:28 -0400, Jeff Layton wrote:
> > On Mon, 25 May 2009 12:42:42 -0400
> > simo <idra at samba.org> wrote:
> > 
> > > On Mon, 2009-05-25 at 06:14 -0400, Jeff Layton wrote:
> > > > On Sun, 24 May 2009 21:05:42 -0400
> > > > simo <idra at samba.org> wrote:
> > > > 
> > > > > Also on the mandatory issue, I wonder if applications
> > > > > ever check it in the real world. If not, then either way is fine,
> > > > > otherwise having the bit set would give precious hints.
> > > > > (Although I prefer the patch as it is rather than leaving permission as
> > > > > open as they are now).
> > > > >
> > > > 
> > > > I doubt applications ever look at this. If they do, then they also need
> > > > to pay attention to the "mand" mount option and I'm pretty sure that
> > > > checking that wouldn't be portable anyway. This change is really about
> > > > whether we want the kernel's VFS layer to enforce mandatory locking on
> > > > these files.
> > > 
> > > Yes if apps never look at it (as I believe too) then it is probably just
> > > useless to set the locking as mandatory, although in that case shouldn't
> > > we prevent sending advisory locks to the server if unix extensions are
> > > not negotiated ? (do we already do that?)
> > > 
> > 
> > Currently, we actually attempt to map posix advisory locks to windows
> > mandatory locks. There are obvious semantic differences here, so this
> > mapping is not perfect, but I think we do as well as be expected given
> > the differences. We could consider disabling this mapping somehow, but
> > in most cases people probably do want some sort of lock set on the
> > server when they set an advisory lock.
> > 
> > This is a pretty complex topic, but I think with this change we'll have
> > a sane set of default behaviors relating to the mode (well, as sane as
> > we can expect given the issues with Windows<->Linux semantics).
> 
> I was thinking that maybe we should send locks only when we explicitly
> make them mandatory. As we are not respecting them on the client anyway
> when they are not.
> 

On the client, advisory locks between competing processes are treated
as normal posix advisory locks. When sent to the server however, the
server treats them as mandatory (primarily because windows has no
capacity for advisory locking).

Again, not a perfect situation, but I think it's the best we can do
given the limitations we have to deal with.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list