Implemented OPLOCK for FreeBsd

Julian Elischer julian at elischer.org
Fri Sep 7 20:03:42 GMT 2001


NWNFS Leases are basically identical to oplocks.

your lease is revoved if someone esle tries to access the file.
The lease only lasts 30 seconds so that if you can cope with a client
becoming unattached, in a way that neither end know whether the other 
end has received the last thing you sent.
(in 30 seconds it becomes irrelevant)
 
On Fri, 7 Sep 2001, Ephi Dror wrote:

> Hi Julian,
> 
> Oplock is different from any other file lock since it is given to the client
> as long as no one else is interested in the file. As soon as anyone else
> either local FS, NFS, NFS4. NQNFS or whatever is trying to access the file.
> The oplock is no longer allowed and an oplock break process starts.
> 
> I don't know much about NQNFS/Lease. I know we don't support it yet.
> 
> Is this lease also should break if someone else try to access the file?
> 
> I believe that all locks, oplocks, NFS Leases and all other locks should
> coexists and the server system must take the right actions to support and
> satisfy them all. Unless of course there is a logical conflict between the
> different locks which can not be resolved without giving one side a
> priority.
> 
> To your question, olock is not exactly lease since it is not for a specific
> time and it break as soon as someone want to access the file even for just
> reading.
> 
> Thanks,
> Ephi.
> 
> 
> 
> 
> > -----Original Message-----
> > From: Julian Elischer [mailto:julian at elischer.org]
> > Sent: Friday, September 07, 2001 2:57 PM
> > To: Ephi Dror
> > Cc: jra at samba.org; 'Jordan Hubbard'; 'Jonathan Lemon';
> > tridge at samba.org;
> > samba-technical at lists.samba.org; jeremy at valinux.com;
> > developers at freebsd.org
> > Subject: RE: Implemented OPLOCK for FreeBsd
> >
> >
> > how do your oplocks interact with (NQ)NFS leases
> > (which are another name for the same thing)
> >
> >
> > On Fri, 7 Sep 2001, Ephi Dror wrote:
> >
> > > Hi guys,
> > >
> > > Actually, the SAMBA API for oplock is generic as I
> > understood it. It is used
> > > by oplock.c which is a kernel independent code which makes
> > calls to kernel
> > > dependent code if such support available. I did look at
> > Linux in term of the
> > > actual implementation and decided not to take the Irix approach.
> > >
> > > So it is not Linux specific.
> > >
> > > It is:
> > > /* if a kernel does support oplocks then a structure of the
> > following
> > >    typee is used to describe how to interact with the kernel */
> > > struct kernel_oplocks {
> > >         BOOL (*receive_message)(fd_set *fds, char *buffer,
> > int buffer_len);
> > >         BOOL (*set_oplock)(files_struct *fsp, int oplock_type);
> > >         void (*release_oplock)(files_struct *fsp);
> > >         BOOL (*parse_message)(char *msg_start, int msg_len,
> > SMB_INO_T
> > > *inode, SM
> > > B_DEV_T *dev);
> > >         BOOL (*msg_waiting)(fd_set *fds);
> > >         int notification_fd;
> > > }
> > >
> > > The implementation of it is a kernel specific.
> > >
> > > So far Linux and IRIX were implemented.
> > >
> > > I went ahead and implemented it for FreeBSD without using
> > kqueue which is
> > > another great way of doing it but unfortunately does not
> > fit our Panasas
> > > system.
> > >
> > > My goal was to implement only what is needed to fulfill the
> > SAMBA API for
> > > oplock and not to develop a generic leasing management on files.
> > >
> > > Jonathan, do you have it implemented already? I don't mind
> > to use and test
> > > it for now.
> > >
> > > Jordan, it is very possible that the correct Engineering
> > way to implement it
> > > must be with using kqueue and I don't mind to help if
> > needed. The only
> > > problem is that for us (Panasas) later on we must move it
> > away from the
> > > VNODE layer.
> > >
> > > For us, at Panasas, we chose fcntl and signal approach
> > because later on we
> > > are going to move the logic of oplock in the kernel from
> > VNODE to other
> > > place that better fit our system architecture.
> > >
> > > Thanks,
> > > Ephi
> > >
> > >
> > > > -----Original Message-----
> > > > From: jeremy at valinux.com [mailto:jeremy at valinux.com]
> > > > Sent: Friday, September 07, 2001 12:56 PM
> > > > To: Jordan Hubbard
> > > > Cc: edror at panasas.com; jra at samba.org; tridge at samba.org;
> > > > samba-technical at lists.samba.org
> > > > Subject: Re: Implemented OPLOCK for FreeBsd
> > > >
> > > >
> > > > Jordan Hubbard wrote:
> > > > >
> > > > > Thanks guys,
> > > > >
> > > > > I also mailed some of this discussion to the freebsd developers
> > > > > mailing list, and some of them have already come up
> > with a way of
> > > > > fully implementing the functionality needed by simply
> > using kqueue.
> > > > > I'm currently arguing that we should use kqueue internally
> > > > and support
> > > > > the Linux API externally, but in the interim I think
> > Jonathan Lemon
> > > > > will be able to help provide a freebsd_oplocks.c that
> > mostly just
> > > > > works out of the box if Ephi is willing to work with
> > him a little.
> > > > >
> > > > > - Jordan
> > > >
> > > > Keeping the Linux external API would be good. We have
> > > > commitments from other (large) UNIX vendors to look at
> > > > the Linux API as a "standard" way of doing this....
> > > >
> > > > Jeremy.
> > > >
> > > > --
> > > > --------------------------------------------------------
> > > > Buying an operating system without source is like buying
> > > > a self-assembly Space Shuttle with no instructions.
> > > > --------------------------------------------------------
> > >
> > >
> > >
> > >
> > >
> >
> 
> 





More information about the samba-technical mailing list