On Wednesday, 25 August 1999 at 18:25:31 +0000, Terry Lambert wrote:
>>> 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-).
I continue to be amazed. That's why I've been keeping out of this
discussion.
>> 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.
How does it do this under FreeBSD? Does it implement it internally?
> 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?
To repeat myself again: none of this is relevant to Vinum. The
original problem I was looking out turned out not to require any other
locking method than was already present in Vinum.
> 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.
Where are advisory locks kept nowadays? I'll discuss this in a
separate message.
> 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'm laying out the disk in the same manner as a hardware RAID-5
controller would do it. Vinum's downward interface is to the disk
driver, not the file system.
I'll send a separate (hopefully last) message to try and sum up what
I'm doing.
Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
