On Fri, May 04, 2001 at 01:33:44PM +0200, Trond Myklebust wrote:
> ??? It'll be a completely useless form of lock if programs can end up
> blocking forever on a set of (from their perspective) valid
> operations.
Umm.. that's your opinion. I don't see how `making them mandatory' would
make this better or worse than if they check for deadlock. If they're
mandatory, a process doing a read() which conflicts will block forever
whether they're checked for deadlock or not.
> Ideally the VFS locking manager wants to provide a service to samba,
> NFS and their ilk, whereby they ask for a lock. If waiting would
> deadlock, send back an immediate answer to the caller. If not, then
> the locking manager should be responsible for scheduling a lock
> immediately after the blocking lock is released, and notifying the
> caller that it can proceed.
did you read my proposal? was that not exactly what i suggested?
> Anything less than that would be an unacceptable step backward
> wrt. the existing code. We don't want to cram more responsabilities
> down on the filesystem-level.
Actually, we _do_ want to give the filesystems the opportunity to handle
their own locks without poking around in the guts of locks.c as lockd
currently does. Did my proposal seem unacceptable to you?
> How about allowing the process to use a cookie to define ownership at
> the kernel level?
>
> For normal processes this may or may not include some combination
> involving the pid, but kernel level server processes could use this to
> save the metadata required to identify the client. I know the NFSv4
> people are keen to implement this sort of thing...
I like this. That may be why the current code checks both owner and
pid fields. Definitely worthy of a comment if so...
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
