[RFC] implementing BSD style locks on NLM (flocks)

[RFC] implementing BSD style locks on NLM (flocks)

[nhorman]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Hey all-
	I was wondering, how much interest there might be in the addition of
support for BSD style locks (flocks) over NLM.  I was thinking that a bit could
be added to differentiate the two namespaces.  Any thoughts appreciated.  

Regards,
Neil
-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman@redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] implementing BSD style locks on NLM (flocks)

[Olaf Kirch]

Hi,

> 	I was wondering, how much interest there might be in the addition of
> support for BSD style locks (flocks) over NLM.  I was thinking that a bit could
> be added to differentiate the two namespaces.  Any thoughts appreciated.  

I looked into this before, and it's not just two "name spaces".  The major
difference is that BSD flocks are associated with an open file handle,
while POSIX locks are associated with a PID.

You could possibly encode the notion of a struct file in the owner
handle that's passed in every lock request, and change the server side
lockd when comparing lock owners.

But I dimly remember there were other issues that could not be mapped
easily to the NLM protocol... don't remember the details: I'd have to
check my archives. These mails may even be in the nfs list archive.

Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [RFC] implementing BSD style locks on NLM (flocks)

[Trond Myklebust]

su den 27.02.2005 Klokka 14:21 (-0500) skreiv nhorman@redhat.com:
> Hey all-
> 	I was wondering, how much interest there might be in the addition of
> support for BSD style locks (flocks) over NLM.  I was thinking that a bit could
> be added to differentiate the two namespaces.  Any thoughts appreciated.  

http://client.linux-nfs.org/Linux-2.6.x/2.6.11-rc5/linux-2.6.11-17-flock.dif

Cheers,
  Trond

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [RFC] implementing BSD style locks on NLM (flocks)

[Olaf Kirch]

On Wed, Mar 02, 2005 at 10:10:34AM -0800, Trond Myklebust wrote:
> http://client.linux-nfs.org/Linux-2.6.x/2.6.11-rc5/linux-2.6.11-17-flock.dif

+	/* We're simulating flock() locks using posix locks on the server */
+	fl->fl_owner = (fl_owner_t)filp;
+	fl->fl_start = 0;
+	fl->fl_end = OFFSET_MAX;

Will this work as expected? Right now, the code sets fl_pid to the thread
group ID (tgid) - but every forked process gets a new tgid, unless you
use CLONE_THREAD, right? So the standard BSD behavior of opening a file
in process A, calling flock, forking and doing the final close in process
B will leave a stale lock, because the unlock call with have a different
pid value.

Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [RFC] implementing BSD style locks on NLM (flocks)

[Trond Myklebust]

on den 02.03.2005 Klokka 19:44 (+0100) skreiv Olaf Kirch:
> On Wed, Mar 02, 2005 at 10:10:34AM -0800, Trond Myklebust wrote:
> > http://client.linux-nfs.org/Linux-2.6.x/2.6.11-rc5/linux-2.6.11-17-flock.dif
> 
> +	/* We're simulating flock() locks using posix locks on the server */
> +	fl->fl_owner = (fl_owner_t)filp;
> +	fl->fl_start = 0;
> +	fl->fl_end = OFFSET_MAX;
> 
> Will this work as expected? Right now, the code sets fl_pid to the thread
> group ID (tgid) - but every forked process gets a new tgid, unless you
> use CLONE_THREAD, right? So the standard BSD behavior of opening a file
> in process A, calling flock, forking and doing the final close in process
> B will leave a stale lock, because the unlock call with have a different
> pid value.

Ah, but we don't actually send the fl->fl_pid on the wire anywhere. That
causes problems even with standard POSIX locks when people do wierd
things with the CLONE_ flags.
Instead we only use the fl_owner field to emulate a "pid".

Cheers,
  Trond

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [RFC] implementing BSD style locks on NLM (flocks)

[nhorman]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Wed, Mar 02, 2005 at 10:10:34AM -0800, Trond Myklebust wrote:
> su den 27.02.2005 Klokka 14:21 (-0500) skreiv nhorman@redhat.com:
> > Hey all-
> > 	I was wondering, how much interest there might be in the addition of
> > support for BSD style locks (flocks) over NLM.  I was thinking that a bit could
> > be added to differentiate the two namespaces.  Any thoughts appreciated.  
> 
> http://client.linux-nfs.org/Linux-2.6.x/2.6.11-rc5/linux-2.6.11-17-flock.dif
> 
> Cheers,
>   Trond
> 
> -- 
> Trond Myklebust <trond.myklebust@fys.uio.no>
> 
Do you know when this will get merged with the mainline kernel?
Thanks!
Neil

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman@redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] implementing BSD style locks on NLM (flocks)

[Trond Myklebust]

to den 03.03.2005 Klokka 13:24 (-0500) skreiv nhorman@redhat.com:
>  
> Do you know when this will get merged with the mainline kernel?
> Thanks!
> Neil

akpm claims that 2.6.12 is meant to be a quick bugfix release, so I'd
guess that we're going to have to wait for 2.6.13 before we can get it
in.

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [RFC] implementing BSD style locks on NLM (flocks)

[Trond Myklebust]

to den 03.03.2005 Klokka 13:24 (-0500) skreiv nhorman@redhat.com:
> On Wed, Mar 02, 2005 at 10:10:34AM -0800, Trond Myklebust wrote:
> > su den 27.02.2005 Klokka 14:21 (-0500) skreiv nhorman@redhat.com:
> > > Hey all-
> > > 	I was wondering, how much interest there might be in the addition of
> > > support for BSD style locks (flocks) over NLM.  I was thinking that a bit could
> > > be added to differentiate the two namespaces.  Any thoughts appreciated.  
> > 
> > http://client.linux-nfs.org/Linux-2.6.x/2.6.11-rc5/linux-2.6.11-17-flock.dif
> > 
> > Cheers,
> >   Trond
> > 
> > -- 
> > Trond Myklebust <trond.myklebust@fys.uio.no>
> > 
> Do you know when this will get merged with the mainline kernel?
> Thanks!
> Neil

I'm pretty sure, yes. The date for merging was last Thursday. ;-)

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

statd -o change

[G. Allen Morris III]

Trond,

I would think that statd should fail if the outgoing port can't be bound
to.  The main reason to bind to a particular outgoing port is because of
a firewall.  If the is the reasond the statd is not going to work on if
it uses a random port.

Allen <gam3@gam3.net>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

statd -o change

[G. Allen Morris III]

Trond,

I would think that statd should fail if the requested outgoing port (-o)
can't be bound to. The main reason to bind to a particular outgoing port
is because of a firewall.  If a random port is used statd will not make
it through the firewall, but the log file will have to be checked to
find out why statd is not working (falling back on randomly chosen port).

Not starting statd seems to be the failure mode if the rpc.statd port
(-p) can't be bound to.

Allen <gam3@gam3.net>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: statd -o change

[Trond Myklebust]

fr den 04.03.2005 Klokka 10:34 (-0500) skreiv G. Allen Morris III:
> Trond,
> 
> I would think that statd should fail if the requested outgoing port (-o)
> can't be bound to. The main reason to bind to a particular outgoing port
> is because of a firewall.  If a random port is used statd will not make
> it through the firewall, but the log file will have to be checked to
> find out why statd is not working (falling back on randomly chosen port).
> 
> Not starting statd seems to be the failure mode if the rpc.statd port
> (-p) can't be bound to.

I'm not against doing this, but it would be a change w.r.t. existing
behaviour, so it warrants some discussion first.

Anyone have an opinion on this?

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs