On Fri, 2005-08-26 at 20:17 +0000, [EMAIL PROTECTED] wrote: > Author: vlendec > Date: 2005-08-26 20:17:39 +0000 (Fri, 26 Aug 2005) > New Revision: 9665 > > WebSVN: > http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=9665 > > Log: > Work in progress. Rename some process_id functions. > > The very first idea is to assume we have coherent fcntl locking (for example > GFS at least promises it), so we can have common messages.tdb, locking.tdb and > brlock.tdb.
IMO that's a reasonable assumption. Most cluster filesystems aim for POSIX semantics so they implement fcntl locking. > This might be slow as hell, but it is a start. Then we need a > notification mechanism, this right now is done by the parent smbd listening on > an UDP port, receiving USR1 signal notifications. Ok, so struct process_id qualifies the pid_t within a machine. Again that seems reasonable. You could also choose something like a node ID and pid_t tuple, but in that case you'd still need to attach an IP address to the messaging system somehow. One trap to watch is that device/inode tuples are not guaranteed to refer to the same file across some types of cluster. This can happen when the device number is dynamically allocated by the cluster node. It's probably worth making this an opaque type. -- James Peach | [EMAIL PROTECTED]