Date: Fri, 03 Oct 1997 12:20:10 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: "Alex.Boisvert" <boia01@castor.GEL.USherb.CA>, freebsd-dlm@primer.i-connect.net Subject: RE: Don't appologize Message-ID: <XFMail.971003122010.Shimon@i-Connect.Net> In-Reply-To: <Pine.SOL.3.91.971003065942.21759A-100000@castor>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi "Alex.Boisvert"; On 03-Oct-97 you wrote: [ With your permission, it is of general interest ] > Hello Simon - > > Maybe I am probably one of the few that *really* wanted to get on your > mailing list about "dlm", but I am very surprised to see that some > people > react this violently to so-called "spam mail" since it is far from being > so. > > I, too, hope it does not represent the FreeBSD community... or else, > will > we have to build moderated/filtered/private mailing-lists in the future? > I hope not. There seems to be so much "anger" on the internet, and > shouting to someone you don't know is always easy. Don't take it > personally, don't appologize, people are overly (?) rude about this. You are not a minority. The count runs 8:2 in line with your message. I KNOW the FreeBSD community is not like that. I think people have a deep need to march to some flag. The level of intensity is somewhat unrelated to the cause and tightly coupled to the personality. I think the leasson learned is worth the price :-) > About DLM. I have read the .DVI file on DLM, I think it's a very good > presentation. It answered most of my questions. I like the fact that > you describe the implementation, since I'm fairly new to UNIX kernel > programming. (I'm been programming in user land too long ;-) You can always change that:-) thanx for the compliment. > I have a few questions, maybe you'll want to answer them on the list or > privately. > > 1-Will DLM be included in FreeBSD 3.0 (when released) > (You did mention that you spoke with the Core Team....) I have no clue. The review process, especially for ``outside'' contribution is complex and lengthly. The concepts and services presented by the DLM are new. I am offering it. Will they accept it? Dunno. > 2-I didn't understand what Spldlm was... I must admit that > I don't know what "spl" stands for? (guess: ... priority level?) The way Unix kernels manage `critical sections'' (A section of code you do not want interrupted. More accurately, a section of code you want to run without danger of being preempted by someone else who will run it again and clobber you). SPL Stands for Software Priority Level. IN the traditional Unix, this is an ordered list of priorities. For example, splclock is higher than spltty, which is higher than splbio. What that means is that if a clock interrupt occurs, it will preempt the keyboard, which can preempt the disk (bio = Block I/O). The problem with that is that a code that executes in spltty can write ober variables that use splbio to protect themselves. In FreeBSD these are simply bitmasks; If I am in splbio, nobody else can be. Period. The spldlm, for example, is a mask of a unique dlm bit and the clock bit. This means that only the clock and the dlm will be locked out, and if the clock is running, the dlm will wait. The reason we created a whole new level (a paractice normally frawned upon by kernel types), is that the DLM needs to run for just about any priority level in the kernel, and may be called from or use networking, SCSI, VM (distributed shared memory), etc. > 3-Do you have links to some information about DBFS? Not yet. > 4-I have asked you this question before, but I can't see any reference > to this in the DLM documentation. Are "leased locks" supported? > (Acquiring a lock for a limited period of say, 10 seconds) This > should > be enforced by the dlm. I would like to add this functionality. We need to discuss this a bit; Since the locks are cumulative, how do we date a lock? Say, we #define READ_LOCK 1 #define CONTROL_LOCK (1 << 1) #define READ_CONFLICT (1 << 1) ... What we say is that READ operations only conflict with CONTROL operations. This allows multiple clients to apply for a read lock. What will happen is that state_ref_count will increment with every request. How do we define the lock's age? From creation time? From the last request? I really do not have an opinion :-) Also, if we choose creation time as its age determinator, is it OK to reset creation time every time a ref_count goes down to zero? Should we have a timestamp on every bit? Or maybe only on the lock as a whole? If we reach an agreement, I will add it to the lock code. It is a good thing to have. > 4-Technical: If a remote lock is asked for, and a timeout occurs > during the dlm-dlm transfert, but a lock is effectively granted on > the remote host... is the lock lost? (the resquesting process will > not know it has acquired the lock...) What happens is this: If a lock has both a local and a remote leg, timeouts are not used. I.e. I do not start the remote leg until the local lock is ackuired. The remote side does not ue timeouts on remote (to him) requests. So, a shared lock first acquires a local lock. If it fails, if fails. Oce the local is acquired, we ask for the remote part. The remote is obliged to serve the request immediately. If that fails, we unlock the local leg and return failure. Now adding ``leased locks'' will complicate this a bit. Right? :-) --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.971003122010.Shimon>