> It would be great if someone could ram such a change through the standards
> committees.
The changes nowadays are coming via "The Austin Group". See
http://www.opengroup.org/austin/ and associated mailing list.
>Alternatively Linux could become enough of a defacto standard
> that we could ignore the standards committee. Barring that, the only
> solution available to us to increase performance is to implement temporary
> byte-ranged locks within the kernel to allow the I/O to be parallelized.
> It isn't necessarily as bad as you think... support for such locks
> already exists in order to deal with POSIX locks, but it would certainly
> be easier if we didn't have to mess with it at all.
Adding more reliance on the POSIX locks works fine if that implementation
is extended to include the common filesystems... in particular NFS file
locking seems needed. A footnote is ensuring the deadlock detection code
finds deadlocks which span multiple filesystem types.
BTW the NFS version 4 protocol includes byte range locking. Version 2 and
3 use a seperate (out-of-band) locking protocol.
> Matthew Dillon
> <[EMAIL PROTECTED]>
--
Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749
Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc
Alternative email address: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
