Implemented OPLOCK for FreeBsd

Julian Elischer julian at elischer.org
Fri Sep 7 14:24:09 GMT 2001


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