> > And how many programmers with nearly (or more than) two decades of UNIX
> > experience it takes to convince someone it really is useful.
Har! 8-).
> I must say, I'm really amazed at some of the opinions that have been
> voiced in this thread. Of course, that's all they are, and they show
> the origins of their owners.
Har again! 8-).
> Any system with multiple concurrent accesses requires locking. Only
> UNIX uses advisory locking. It almost does the job, so nobody has
> tried to fix things. But that doesn't make it right.
UNIX doesn't do this _at all_ well for "hosted OS's".
The NetWare for UNIX product, which I worked on the attributed FS
(with resource forks and multiple namespaces) and the lock coherency
model on is one example.
We had to add hooks into the fcntl() call in the FS to support
this.
Something that might be interesting to look at in this regard is
the latest SAMBA code.
The latest SAMBA code has an OS OPLOCK (Opportunity Locking) API
that it will utilize, if it is present (currently only on IRIX),
which deals with the lock coherency issues.
Note that since SAMBA externalizes via SMB an interface that has
to implement NetBIOS calls, and those, in turn, externalize via
the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA
has to support mandatory locking.
In effect, it is an API which externalizes much of the same types
of operations that implement LEASE operations used by the current
FreeBSD NFS server implementation.
I don't know if this would be quite sufficient (it's been a while
since I did a lease and order of operation audit on the VFS code,
and written up patches to support Jordan's class project of making
the NFS server locking work), but it should be a healthy start
down the right road, I think.
Might even fix a couple of NFS bugs as a side benefit...
Anyway, Sean's also right about needing mandatory file locks for
binary emulation of other platforms (some of which Sean coded for).
Are file locks sufficient for Vinum, Greg? The current lock
structures in FreeBSD are hung off the backing inodes (of which
specfs has none available that are not themselves abstract),
and the spec_advlock() function returns either EOPNOTSUPP or
EINVAL, based on the arguments its given.
IMO, unless the lock list is hung off the vnode (I guess you
could hang the mandatory locks there, and leave the advisory
ones alone, but that's kind of a waste, especially if the locking
code can be reused), you aren't going to be able to do range
locks on your stripes.
Am I not understanding how Vinum's RAID 5 is implemented? Are
you using files for the stripes, or are you laying out the disk
as a true RAID 5 controller would lay it out?
I guess this all moderately re-begs the "struct fileops" question,
yet again, too... 8-(.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
