Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Aug 1999 19:53:22 -0400
From:      Christian Kuhtz <ck@adsu.bellsouth.com>
To:        Greg Lehey <grog@lemis.com>
Cc:        Thomas David Rivers <rivers@dignus.com>, bee@wipinfo.soft.net, hackers@FreeBSD.ORG
Subject:   Re: Mandatory locking?
Message-ID:  <19990825195322.D4723@ns1.adsu.bellsouth.com>
In-Reply-To: <19990826090933.T83273@freebie.lemis.com>; from Greg Lehey on Thu, Aug 26, 1999 at 09:09:33AM %2B0930
References:  <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com> <199908251005.GAA95394@lakes.dignus.com> <19990826090933.T83273@freebie.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 26, 1999 at 09:09:33AM +0930, Greg Lehey wrote:
> On Wednesday, 25 August 1999 at  6:05:11 -0400, Thomas David Rivers wrote:
> >> All the files under Tandem's NSK has mandatory locking. The file cannot be
> >> opened if another process has it opened. some thing like
> >>
> >>   * if the file is opened for reading, any one can open it for
> >>     reading but opening for writing gives error
> >>   * if the file is open for writing, it can't be opened for
> >>     read/write
> >>   * if the process holding the file is killed, the lock is gone
> >>   * it is possible to get the pid of the process(es) which has
> >>     a given file open (like which process has file "xyz" open?
> >>     kind of query). btw, is there any way to get this info now in FBSD?
> >
> >  This sounds interesting...
> >
> >  But - aren't there NFS issues?  I mean, in stateless access to
> >  a file - how do you know if the process holding the file is killed
> >  if it's remote?
> 
> NSK is a prorietary operating system ("NonStop Kernel", previously
> known as Guardian, previously known as TOS), not UNIX.  There is no
> NFS, and there is no distinction between network access and local
> access: all goes over the message system.  When a file is closed, its
> locks are released.

How does this message system handle releasing stale locks when components 
talking to the message system die unexpectedly?  Is there some sort of aging,
override or timeout mechanism to purge stale locks?

-- 
Christian Kuhtz, Sr. Network Architect                    BellSouth Corporation
<ck@adsu.bellsouth.com> -wk, <ck@gnu.org> -hm            Advanced Data Services
"Affiliation given for identification, not representation."   Atlanta, GA, U.S.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990825195322.D4723>