Hello hackers,
man page for flock(2) and fcntl(2) reads that a system call returns
EOPNOTSUPP if file descriptor refers to an object that does not support
file locking.
However, it seems that it is not always true. For example, if underlying
object is a device or a fifo returned error code
Hi.
I've recently upgraded my main work machine to -CURRENT in an
environment where much of the world is mounted via NFS. The NFS locking
via rpc.lockd/rpc.statd doesn't seem to be too stable, and the -L
behavior described in mount_nfs(8) works much better for me.
Unfortunately, I can't seem to c
"Andrew R. Reiter" wrote:
> :He could also maintain a local cache of this per vnode, basically
> :maintain a mirror of the lock list locally in order to see if a remote
> :op must be done.
>
> Isn't this sorta like coda?
Lock cache, not data cache.
It's "sort of like":
http://www.blackflag.ru/
Alfred Perlstein wrote:
> He could also maintain a local cache of this per vnode, basically
> maintain a mirror of the lock list locally in order to see if a remote
> op must be done.
I think we are talking past each other.
This is what I've been suggesting since my first message,
but suggested
t; > Which still means that the correct functionality is implemented, but we
> > only try to unlock files that have ever been locked before, or where we
> > are sharing a file struct with another (related) process and one of them
> > has locked the file.
>
> Do you expect
* Andrew R. Reiter <[EMAIL PROTECTED]> [020515 09:54] wrote:
> On Wed, 15 May 2002, Alfred Perlstein wrote:
>
> :* Terry Lambert <[EMAIL PROTECTED]> [020515 01:36] wrote:
> :> Alfred Perlstein wrote:
> :> > As Terry stated you can't do that, however you could cache that the
> :> > VNODE has a loc
On Wed, 15 May 2002, Alfred Perlstein wrote:
:* Terry Lambert <[EMAIL PROTECTED]> [020515 01:36] wrote:
:> Alfred Perlstein wrote:
:> > As Terry stated you can't do that, however you could cache that the
:> > VNODE has a lock, that would reduce the requirement for calling the
:> > ADVLOCK VOP.
:>
* Terry Lambert <[EMAIL PROTECTED]> [020515 01:36] wrote:
> Alfred Perlstein wrote:
> > As Terry stated you can't do that, however you could cache that the
> > VNODE has a lock, that would reduce the requirement for calling the
> > ADVLOCK VOP.
> You'd really have to know when the lock list went t
Alfred Perlstein wrote:
> As Terry stated you can't do that, however you could cache that the
> VNODE has a lock, that would reduce the requirement for calling the
> ADVLOCK VOP.
You'd really have to know when the lock list went to NULL, to get
any benefit out of it, since locking would still end
Btw, Terry's implementation of this ported to 4.5-STABLE could be found here:
http://www.blackflag.ru/patches/nfs-client-and-server-locking-4.5-STABLE-20020312.diff
I've been testing it continuously for a month or so with an NFS server
on Solaris. Particularly, that was a combination of Connecta
* Terry Lambert <[EMAIL PROTECTED]> [020514 22:58] wrote:
> Richard Sharpe wrote:
> > Hmmm, I wasn't very clear ...
> >
> > What I am proposing is a 'simple' fix that simply changes
> >
> > p->p_flag |= P_ADVLOCK;
> >
> > to
> >
> > fp->l_flag |= P_ADVLOCK;
As Terry stated you
are sharing a file struct with another (related) process and one of them
> has locked the file.
Do you expect to share the same "fp" between multiple open
instances for a given file within a single process?
I think your approach will fail to implement proper POSIX
file locking semant
On Tue, 14 May 2002, Terry Lambert wrote:
Hmmm, I wasn't very clear ...
What I am proposing is a 'simple' fix that simply changes
p->p_flag |= P_ADVLOCK;
to
fp->l_flag |= P_ADVLOCK;
And never resets it, and then in closef,
if ((fp->l_flag & P_ADVLOCK) && fp->f_type
Richard Sharpe wrote:
> I might be way off base here, but we have run into what looks like a
> performance issue with locking and file closes.
[ ... ]
> This seems to mean that once a process locks a file, every close after
> that will pay the penalty of calling the underlying vnode unlock call.
Hi,
I might be way off base here, but we have run into what looks like a
performance issue with locking and file closes.
We have implemented a distributed file system and were looking at some
performace issues.
At the moment, if a process locks a file, the code in kern_descrip.c that
handles
We have come across a problem wrt to a network file lock manager.
Consider the case of a lock on a local file, and a request from a remote
machine to lock that same file. fcntl(fd, F_SETLK, &fl) will return
immediately with EAGAIN (this is for an exclusive case, of course),
F_SETLKW will block
16 matches
Mail list logo
