Subject: Re: CVS commit: src
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 06/24/2004 09:35:59
> > > > ... it as a requirement that file
> > > > systems do real, hard-core locking. And given the state of things when I
> > > > started, that was a very good thing.
> > >
> > > why do you think that exposing a lock is a requirement?
> > I'd like to ask the same question differently.
> > Suppose a file system's VOP_LOCK() and VOP_UNLOCK()
> > are no-ops, and the file system can be trusted to
> > do the right thing (not really that hard) for the
> > primary VOPs (LOOKUP, READ, WRITE, etc). What
> > semantics would break?
> Whatever access callers of the file system expected to be serialized that
> now aren't. i.e. a case where a caller called VOP_LOCK() and expected an
> exclusive lock is now in place. Especially if it expected that lock to be
> held across a call to ltsleep().
yes, we have such callers, unfortunately.
they should be fixed eventually, IMO.
> Also, for things like delete and rename, would it be so easy? Or file
yes, it's easy. see nfs client.
> > >From VOP_LOCK(9)
> > VOP_LOCK() is used to serialise access to the
> > file system such as to present two writes to
> > the same file from happening at the same time.
> > Why? Is this a semantic of the file model? Or is
> > this a context to make things "easier" on the
> > underlying file system?
> It is file system semantics. A call to write(2), barring errors, is
> supposed to be atomic. Thus if you have two write calls that overlap, the
> overlapping data are to have come from one call or the other, not some mix
> of both.
because we use a single VOP_WRITE for write(2),
there's no need to expose vnode lock to upper layer for this reason.